An AI proposal may clearly state the development fee while leaving a business owner uncertain about costs after people start using it. Retrieval, repeated tool calls and staff review can all contribute to the operating workload.
A useful estimate separates setup, usage and continuing ownership, then connects them to work the business recognises: a completed and checked request, for example, rather than a single model call.
Worksheet one: separate starting costs from continuing costs
| Cost area | Examples to include | Who can supply the information |
|---|---|---|
| System preparation | Process analysis, development, connections and testing | Project team and developer |
| Data preparation | Cleaning, organising, checking sources and access | Data owners |
| Operation | Hosting, storage, retrieval, models and tools | Service-account administrators |
| Human participation | Reviewing answers, correcting records and handling exceptions | The operating team |
| Continuing changes | Updating knowledge, retesting and repairing connections | System owner and maintainers |
Some items may be included in development, some charged separately and some supplied through the customer's own staff time. Identify them explicitly to avoid omissions or double counting. Existing hosting may provide useful capacity, but it does not establish that retrieval or model-processing charges are already covered.
Worksheet two: trace one completed unit of work
Suppose the system prepares answers from company documents. A question may require an access check, retrieval, selection of relevant passages, a generated answer and staff review. An ambiguous question can require clarification; an unavailable tool can lead to another attempt.
Each step uses different resources. “Number of users multiplied by the price of one model call” therefore does not establish total operating cost without accounting for interaction rounds, data size and human handovers.
A planning formula is: cost for a period = baseline system cost + workload × average cost per work item + maintenance and review. Define the workload unit and explain where failed attempts and retries are included.
After a trial, also divide the period's cost by the number of items that actually met the acceptance criteria and completed. Counting only system invocations can make the unit cost look attractive while unfinished work returns to employees for reprocessing.
Worksheet three: compare three operating conditions
Start with ordinary usage supported by available evidence. Then consider a busy period and a difficult or degraded workload. Record the basis for each assumption; a blank awaiting evidence is preferable to an invented figure.
Ordinary usage: Use the observed request volume and representative document sizes. Estimate the human-review share from the trial rather than assuming almost every answer will be accepted.
A busy period: More simultaneous requests can affect capacity limits and waiting time as well as the bill. A monthly average can conceal a period in which the service cannot keep up.
Difficult cases or failures: Longer documents, repeated retrieval or an unavailable connection may increase work per request. Check retry limits and the handover route. Repeated unsuccessful attempts should not be allowed to consume resources indefinitely.
Update these assumptions from trial evidence. Revisit them when adding new users or task types too. A similar request count does not guarantee the same cost per request if the work has changed.
A budget notification is not a usage stop
Distinguish an alert from an enforced consumption rule. Providers differ in what they support. If the system must pause or restrict usage at a condition, design and test that behaviour. Enabling an email warning does not establish that spending will automatically stop.
Assign an owner for alerts and a response to unusual activity. Options might include limiting certain work, pausing retries or routing requests to people. Tell users which capability is temporarily unavailable and how to continue, rather than leaving them with an unexplained error.
The AWS Well-Architected cost guidance emphasises visibility into consumption, matching resources to demand and continuing improvement. These are useful operating questions regardless of the provider selected.
Ask for a proposal that can be compared
Request explicit inclusions, external-service charges, account ownership and the workload assumptions behind the estimate. Where a package includes an allowance, establish what happens when it is exceeded and who authorises additional consumption.
Ask about post-launch changes too: adding a document collection, revising response rules or adapting to a destination's changed data format. These may fall under maintenance or separately scoped work depending on the agreement. Identify the distinction before starting.
Comparable proposals describe costs under equivalent assumptions and identify uncertainties that still require a trial. A workable budget accounts for the work performed by the system and the responsibilities retained by people, with a way to observe and adjust both as real usage changes.
If costs remain unclear because the task is not defined, start by choosing between a chatbot and an AI agent to establish scope and review responsibilities before estimating usage.
Plan AI development, running costs and ownership together
Talvyn Labs assesses and builds AI systems around the work, expected usage and data connections involved. Share the workflow, approximate user volume and your constraints. We can separate development scope, service usage and ongoing responsibilities before you decide.
Discuss AI costs