I am having a current experience from a customer's perspective on usage based contracts.
having a VERY frustrating experience with Iterable making us switch to an opaque multi-combo usage contract and this article has some good points.
This turned into a long vent, but points I would additionally add from my current experience as a customer:
7: consistency in pricing & contracts
8: transparency
9: ability for customer to calculate themselves (might add into #4 predictable)
there was a recent thread on ousting their CEO which mentioned these sales tactics. To me personally Iterable is now a totally different company, feels like Oracle level behavior pushing onto my small company.
We've been long term customers, to the point my first contacts and support requests were with the ousted CEO Justin himself.
Last year contract renewal they tried to force this but a higher manager intervened. No luck this time; radio silence.
#7: Is pricing consistent:
Having consistent contracts over long time frames is important to many small and large customers. Changing structure dramatically during a contract renewal feels like holding us hostage, and contract length is only one year.
If you make a change in pricing how does it affect existing customers?
Big one for me. I strongly dislike even if it might save a small amount of money - and that's a big if.
I feel like companies are taking hundreds of millions in VC $ and are then forced to hold you hostage to pay back the investors.
#8: Is pricing transparent:
How is pricing calculated and is it clearly understandable and useable for #4 predictable?
For me this is the biggest problem. We went from a simple contract based on unique emails charged CPM.
Their new pricing combines unique emails + send volume + custom events.
Custom events are the oddest to charge for. First, they were a big value proposition originally something new to ESPs. Like the article says could be similar to salesforce charging for Opportunities it's in iterables best interest for customers to get value using unique (or what once was) features.
#9: is the customer able to calculate their usage charges themselves?
This is a horrible point: there is no way, at least that I know of, to actually count how many custom events we sent in with their GUI !!!!
only on my backend. I asked they never replied so I don't think I'm missing something obvious.
The points in the article:
#4: Is usage predictable for the customer?
Not really. We are an agency clients come and go all the time, each having wildly different email lists. In politics things grow dramatically during the last 3 months, but it's unpredictable.
Question #3: If the customer throttles usage, is that ok for your strategy?
It would result in less revenue for Iterable on all three usage charges.
First for us would be cutting out custom events that don't provide us with the value for the cost, but are nice to have and original value prop.
We already throttle anyways for 'dead' contacts remove them from Iterable DB before billing.
I can see this as a strong argument for charging simply for email send volume, as sitting rows in DynamoDB are super cheap compared to SES. At least switching to that alone makes sense logically for costs on their end.
But they should have thought of this years ago or rolled out to new customers only.
Question #5: Is the pricing axis large-scale?
The proposed tranches are large scale for our numbers, but if you are moving to complicate this why not just charge CPM and discount at higher levels? I currently don't know the proposed CPM overages for any of the 3 usage items, and if they break them out that breaks the veil of their combined opaque new pricing.
It looks like not a big discount at high end usage but again hard to tell.
Our existing old contract was very simple and did have significant large-scale pricing savings.