[moxli]

> AccessOwl calculates billing based on the number of active Slack users, excluding Single-Channel Guests and service accounts, as this is usually the closest measure to your number of active employees. The billing amount is updated prorata each month and before each payment, based on the number of users in your Slack workspace.

https://www.accessowl.io/pricing

How does pricing work if Slack is not used?

[jorams]

I don't think that's possible, the "Start Trial" button immediately redirects to Slack.

This does seem like a weird restriction. Nothing about the product otherwise seems Slack-specific.

[mathiasn]

Slack is required for AccessOwl. It's used for things like approval workflows, task management and notifications in general.

What do you use instead?

[haswell]

This severely limits the usefulness of a product like this.

Core aspects of the product like workflows and task management should not be tied to a chat vendor in my opinion, and would make me extremely nervous as a potential buyer due to your complete dependence on what SF does with Slack.

I’ve also worked places that strongly dislike Slack and won’t touch it since it was acquired by Salesforce. Ironically, your product would cause Shadow IT deployments (of Slack) in such environments.

Sharing these concerns because I think the product is a really useful concept, but your roadmap for these core functions would mean the difference between considering and completely passing over AccessOwl, i.e. for some subset of potential customers, the hard dependency on Slack is a complete blocker.

[mathiasn]

Depending on the point of view it can also be a strength. Actually many of our customers like that we're in Slack because their people are already there:

- no login required to request an access - they don't need to "learn a new application"

So for end users that's great. There is still a web app for admins with more details.

But I can see where you're coming from. We plan to offer an alternative to Slack to be independent if the customers want that.

[haswell]

It sounds like you may have found your niche with existing Slack customers and if that works for you that’s great.

I don’t agree that this is a “strength”, because it limits the growth potential of the product while coupling critical functions to the whims of a 3rd party vendor. I absolutely do see how it’s beneficial for you in this early stage because it allows you to deliver a straight-forward experience for this particular user base (Slack customers) without building your own UIs. But that position of strength is fundamentally limited to that specific group. Move beyond it, and not only would using the product now require the adoption of a non-standard chat tool, but the core function of your product is completely orthogonal to chat making the Slack requirement also appear really odd. That group won’t have muscle memory for Slack or know all of its key features. That group will not benefit from any of the familiarity your current customers find compelling.

And back when I was a Slack customer (I actually like Slack and prefer it to the alternatives) I’d still be raising concerns because of the tight coupling with Slack features.

Not trying to just criticize your decisions here, but trying to elaborate on an outsider’s perspective as someone who has been in the position to bring this kind of product on board at large companies, and as someone who has dealt with the pitfalls of building products that have 3rd party integrations.

Best of luck to you on all of this and it’s good to hear there’s an alternative on the roadmap.

[akeck]

A lot of companies are MS O365/Teams shops.