thanks for all the responses guys. There are a couple of things I wanted to point out
- some said above that alfred by definition is a personal assistant and is not likely to be used at an enterprise level.
My response is just b/c it isn't historically associated with enterprise, that doesn't mean it cannot be tailored to fit enterprise. For example Slack was born out of IRC chat (something that was documented quite nicely by Scott Berkun in A Year without Pants).
- there is a point that people won't appreciate/like selling alfred workflows on the forum/packal etc.
Alfred (and the forum and packal etc) need not even be the distribution point. As a matter of fact the product itself need not be restricted to alfred users (for example the business logic can be wrapped by an api, which get accessed by alfred and wox for windows for example). In that case the sales channel could be a stand-alone website (of course that would entail kind of reinventing the sales channel from scratch, as opposed to getting on known market places like app store etc.. but that just makes it a bit harder, not impossible).
Anyways let me explain where I'm coming from a bit more: I've worked as an engineer for many start-ups, and then I somehow started running my own (lobolabshq.com) and started specializing in setting up processes at start-ups so that they can be "remote ready", after that I scale their team by hiring remote engineers (you can see a detailed description of one such experience here with vibereel.com).
So when we talk about "remote ready" processes, there are processes/protocols that I have setup in many start-ups that just proved to work again and again, but obviously there is always a lot of room for improvement. So for example I created a protocol for creating an issue on jira/github/gitlab etc, protocols for slack communication (ie users have to put their usual availability hours on their slack profile, slack channel prefix where each prefix covers a project or group of projects and usually have a development channel, a schedule channel (people check in/out) and a commitments channel (people put what they're committing to accomplishing that day using ticket numbers etc etc).
As we all know slack isn't the place to document such protocols, so I documented these processes in Google docs (effectively making google docs a wiki). The thing is that google docs isn't meant to be a wiki, it just stores documents and you can improvise the structuring of your documents as you want. You can set google docs that explains that structure all you want, but you'll still have people who are confused about this labyrinth of documentation.
Anyways long story short: I envisioned alfred and alfred like quick launcher apps (for other platforms like wox) to be the command line tool for the average Joe in start-ups where they can access all these docs and actually work with them. So me logging my own hours using an alfred workflow is a very simple "action" of a laundry list of common actions that are performed in these remote start-ups. I can probably release a couple of them free on alfred, but then sell a big collection of them as a package to enterprise. Probably part of the package would be "scaffolding" a whole google drive/slack structure for a remote start-up. Providing such a service not only would make people more productive, it would also give them a time-tested process wrapped in a command line that will just make them more effective in what they do.
This is my vision, and I honestly think people would be happy to pay for it. Obviously the key here is scale: I'm not interested to be hired by someone to do their custom workflow and get a McDonald's salary, I want something I can package and sell at scale to make some "full time"-able coin.
Bonus: I gotta admit this idea has pivoted a lot.. Initially I was thinking of simply creating a chrome add on that wrapped google docs with a wiki interface (see this fake press release) But then I liked the simplicity and power of alfred. So now I'm in Alfred land