|
|
|
|
|
by danpalmer
1479 days ago
|
|
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. |
|
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!