[kwent]

I appreciate the feedback.

We tried to think of our pricing as the value a user would get out of the tool. The amount of time and headache we'd save them when actually responding to an incident. We've found a lot more pushback for smaller sized companies (e.g. <20 eng) but have also realized the challenges of managing incidents are less pronounced.

Just curious for my own learning, is the thinking behind "should be cheap" motivated by potentially not everyone would need access to tools in monitoring, alerting, response?

[danpalmer]

For non-technical purchasers, it makes sense to price by the value the organisation will get out of the tool. However for tools that technical users are involved in you have to fight against the "I could build this myself" factor.

There are lots of tools that are basically CRUD apps, or maybe CRUD with a chat interface in this case, which are fundamentally straightforward to build a first-pass version of. I'm sure the product here is far better than a first-pass version, but it's an uphill battle to justify that when the pricing is on the value to the user, rather than based on the cost to build.

Another complicating factor for this market in particular is that there are often two types of users: regular and infrequent. In my experience tools like this would be used heavily by the engineering team, but there was value in having everyone in the org have access to the tool. There may be 10x the number of non-engineers, but they're often worth 1/10th or less to have on the platform. Each person isn't worth having by themselves but having everyone there is worth something. Nickel-and-diming customers on the basis of lots of users who rarely use the platform isn't great.

Edit: also, don't have a pricing page with no pricing on it.

[kwent]

This was an awesome response and you absolutely nailed it.

A vast majority of our customers actually have some sort of internal bot built. It's quite limited usually and largely focused on the "creation" portions of an incident. Most commonly create an incident channel, create Zoom, link to a few integrations, and that seems to be it.

But depending on who you speak with that can be enough which is totally fair. Especially when complexity and incident volumes are low.

And yes agree not every user on the platform will value it the same. An SRE vs. someone in legal will find different value out of it. Our goal is to make this accessible to the entire org not just engineering teams.

Thank you for the feedback on the pricing page as well!

[danpalmer]

One last thought, if engineering teams paid "what it was worth" for a tool for every piece of their stack, they'd have no money for engineers or building an actual product. It is very easy to spend the entire personnel budget again on tools, and most companies just can't do this. At that point, you're competing with your competitors for business, and with other unrelated service providers for budget.

[sokoloff]

If you charge the value a user gets out of the tool, an economically rational user would be indifferent between buying your tool and not buying it. (Given that choice, a user should probably avoid buying as they’re economically no better off, but now they have the complexity of another vendor to manage for no net gain.)

There are well established reference points that you’re at least nominally going to be compared to. “Is X worth more or less than Slack? O365? Box? gSuite?”

That is probably going to create a stronger anchor on perceived value than a carefully calculated product of reduction in MTTR * cost of outage * frequency of such savings.

[porpoisemonkey]

Not the OP, but in one of the smaller companies (~30 people/~12 engineers) you describe that's currently looking for a tool like this.

I can't actually see the pricing because it's behind a nebulous "contact us" link, but if this is more than about $5/user/month I would definitely balk at the price.

Larger companies already have dedicated platform and tooling teams with enough technical talent and bandwidth to build this sort of solution (I've seen something eerily similar to this at a previous employer that had about ~75 engineers). IMHO it's the small companies that need off the shelf incident management because they have very few people to dedicate to solving this problem and need a way to manage the communication chaos that incidents can cause.

[ezekg]

You'd balk at more than $5/user/mo? For 12 engineers, that's only $60/mo (and for all 30 employees, $150/mo). I'd guess that you're not a C-level since you said you'd balk at that price, which is incredibly cheap. I pay more for my business's status page.

[kwent]

Thank you for the feedback, we'll make some changes to the page.

Agree on those companies having technical talent and in fact a vast majority of our customers came to us with their own bot built out that resembles of our features. It really comes down to the age old question, build vs buy? The maintenance cost and feature enhancements for something owned in-house can be burdensome but I am obviously bias towards it.

We've seen it takes usually at least an engineer one whole quarter to standup the basics of nailing creating incidents right with some basic automation.

But the times customers decide building it themselves isn't worth it is often a) someone that owned it had left the company and b) its a big distraction from their core focus/ has become a full-time job to maintain.