How to Charge per Query for SaaS?

-We have an existing SaaS service ( https://ClearRoadmap.com to see an overview video or subscribe to a trial account) that is structured on a "per Seat" interface model with a client side query tool.

.

We've had a request from a client to provide our data as anAPI basedfeed into Tibco Spotfire.

.

One option is to continue to do this on a Per Seat basis. This has the advantage of pricing simplicitly and payment simplicitly - OTOH it encourages the client to pull as much of our data as possible and that may be something we wish to avoid

.

The other option is charge on a per-query basis through our API. thus every query tranasaction would be charged "x"

.

The gotcha is that we don't know what the client's potential usage profile would look like. Our enterprise seat works out to be around $5/hr. Assuming they had a dedicated person doing the queries, and they did a query every 6 minutes, that works out to about $0.50/query. .

OTOH, I actually would expect the query rate to be less than 10 queries/hr 8x5x52. I would expect it to be more like 6 x 4 x 40 which would put the API query pricing at around $1/query.

.

The concern with that price point is that I think it prices us out of the market perceptually.

.

Perhaps a hybrid might work where we chargea fixed enterprise seat cost that is say 50% of the normal cost. and then charge 50 cents per query thereafter

So does anyone have experiencein pricing a SaaS data source vs. a dedicated SaaS client ?

My experience with charging per usage/volume vs. per seat/installation is that it's much more difficult for the customer to deal with. It's challenging for them to predict their usage so it's more difficult for them to accurately budget. And if your early user finds it useful they can quickly burn thru a lot of $$, which effectively penalizes an early user that you want to be an advocate.

While a per usage plan is aligned with your costs it's not aligned with how many organizations need to plan and budget. It's often best introduced after you have significant adoption and/or market share, when a customer has to use your services and also has a better understanding of their projected usage.

Have you considered a bucketed per seat model that has caps with overages? Let's say a light, medium and heavy plan, each with an increasing number of queries (and a decreasing average cost per query) along with an overage plan. Another modification of this approach I've seen is to adjust their plan each month based on the previous months usage - for example they are on the Medium plan, their usage spikes up and instead of charging overages that month you bump them to the Heavy plan the following month.

You wrote "...it encourages the client to pull as much of our data as possible and that may be something we wish to avoid."

Why is that?

First, what is a seat? I gather that Tibco Spotfire is a reseller. Do they represent one seat, aggregating a variable number of ends users, or would each seat still represent one end user?

In the latter case, I would prefer subscription. I'm guessing that an end user's demand curve is not very elastic. That is, they need what they need, and they are unlikely to gorge on much more just because it's incrementally free. Whereas your cost curve is probably very steep. That is, your full unit cost per end seat probably drops rapidly with volume. So subscription is preferable because the advantages you have cited (simplicity, perception) while posing little risk to per seat profitability.

I would exhaust all possible ways to price per end user. Failing that you have no choice but to price somehow by volume: per transaction, tiered subscription, hybrid.

Thanks for the response Tim. No Tibco is not a reseller. The client is using Tibco Spotfire for various bits of analysis. Essentially Tibco Spotfire is Excel Pivot Tables done with a UX that a human being can figure out.

So I'm not sure how the client is licensing Tibco. I imagine it too is a per-seat license. My concern is that because it is essentially a spreadsheet - if they pull a lot of our data, they could potentially do future pulls and analysis from the pulled data rather than coming back to our dataset.