The price per request looks small, so usage costs disappear into a footnote. Later, each case generates several requests, retries and a longer response than expected. The original estimate counted only the cleanest route.
Estimate repetitive AI usage from the number of cases, requests per case, retry behaviour and the supplier's actual billing unit. Keep this operating-cost estimate separate from the wider business case, which also includes people, implementation and maintenance.
Photo by Sasun Bughdaryan on Unsplash.
Find out what is charged
Read the current official plan or pricing information for the product being considered. Charges may follow different models, so do not convert every tool into an assumed price per prompt.
Microsoft's token guidance explains that generative services often price input and output tokens separately. That is a reason to identify the actual billing model, not a universal statement about every assistant subscription.
Record the currency, billing period, included allowance and date observed. Keep any unresolved plan restriction visible rather than estimating around it.
Map the request path
For one accepted result, list:
Normal requests required.
Additional requests for clarification or revision.
Expected retries after a technical failure.
Source material included in each request.
Typical and unusually large outputs.
Any separately billed supporting service.
Ask the technical or account owner which usage measurements the platform exposes. Do not equate a conversation message with one billed unit without confirming that relationship.
Use explicit illustrative arithmetic
Suppose a fictional service charges two pence per defined unit. Two hundred weekly cases use three units each, with sixty additional units for revisions and retries.
The estimate is six hundred and sixty units multiplied by two pence, or £13.20. These are invented teaching figures, not a current supplier rate or a forecast for your business.
If difficult cases use twice as much material, the model needs a separate case mix. A single average may be sufficient initially, but record what it hides and observe real usage before expansion.
Separate volume growth from price change
Build a cautious scenario in which more cases require revision or the source pack becomes larger. Also show what happens if the quoted rate or included allowance changes.
Avoid assuming every source upload, cached result or retry is charged the same way. Verify the actual product rules with its current official documentation.
Do not reduce essential context just to make the estimate smaller. The usable result and agreed controls remain part of the task.
Compare the estimate with observed usage
During a permitted evaluation, record real cases and the reported consumption for the same period. Investigate differences in request count, case mix or billing interpretation.
Keep the cost worksheet understandable enough for another owner to update. It should show which assumption would change the decision, rather than deliver a precise-looking total whose inputs nobody can explain.
For related practical guidance, see building a wider AI business case and planning the separate human-review workload.
Hili Consulting can help build a transparent volume-based estimate of AI usage charges. Arrange a free 30-minute consultation and bring one example of the work you want to improve.
