The cost of an AI automation project depends on the workflow being changed, the systems it must connect to and the standard the result must meet. Model usage is one part of that cost. It does not account for discovering the process, preparing the data, building the integration or operating the result.
A useful quote makes those parts visible. If two proposals have very different prices, the first question is whether they include the same work. A demonstration using sample data and a customer-facing production system are different deliverables.
Separate the initial build from ongoing operation
I would ask for implementation and operating assumptions separately. The initial work may include discovery, integration, configuration, evaluation and release preparation. Ongoing costs may include hosting, provider usage, support, source maintenance and changes requested after launch.
Each category needs a clear boundary. Does support cover incident investigation, or does it also include adding new workflows? Does the build include cleaning source documents, or will your team provide approved material? These questions often explain a price difference better than a comparison of hourly rates.
| Cost area | What changes the estimate | What the quote should clarify |
|---|---|---|
| Discovery | Unclear rules, several departments or undocumented exceptions. | The assessment output and decisions it will resolve. |
| Integration | Number of systems, access quality and permitted write operations. | Included endpoints, records and dependencies. |
| Validation | Consequences of a wrong answer or action. | Acceptance cases and who reviews them. |
| Operation | Usage, service expectations and frequency of change. | Recurring charges, responsibilities and exclusions. |
Describe workload in business units
“We need a chatbot” says little about the workload. A more useful estimate starts with conversations, documents or transactions, their typical complexity and the proportion requiring review. Include peak periods if the operation is seasonal.
For example, a document workflow should distinguish short standard forms from long mixed attachments. A support assistant should distinguish answering published questions from investigating an account-specific issue. An average request count can hide these differences.
You do not need perfect measurements. A small representative sample, a rough volume range and an explanation of the busiest period give the estimator something concrete to work with.
Reduce uncertainty before fixing the price
A fixed-scope price is most useful when the inputs, integration access and acceptance conditions are understood. If a dependency has not been inspected, the proposal should identify the assumption and explain what happens if it proves wrong.
One option is a separate discovery stage. Another is a deliberately small implementation with explicit exclusions. The important point is that uncertainty is discussed before it becomes a disagreement about delivery.
Ask how changes are handled. Adding another data source, language, customer group or action can affect several parts of the system. A change process should explain the impact on cost and schedule before the work proceeds.
Review the cost of incomplete automation
An inexpensive system can still create a large manual review burden. When comparing options, ask how much work stays with your team and whether the implementation makes that work easier. A draft that needs extensive correction may offer less value than a narrower task completed reliably.
Useful acceptance measures include review time, correction effort and successfully completed tasks. Translate those into your own operating assumptions instead of relying on a promised savings percentage.
I quote after understanding the system and scope. An initial request can include the workflow, relevant platforms, approximate volume and desired outcome. Access to credentials or private customer data is not needed to begin that conversation.
An example first-phase scope
Here is how I would scope the first phase of a support assistant for an online store, the kind of work described on the AI assistants for support and commerce page. The example lists work rather than figures, because the price follows from the systems and the standard involved.
Included in the first phase:
- Reading a sample of real conversations and writing down which questions the assistant must answer, which it must refuse and what evidence each answer needs.
- Answers from approved sources: the help pages, policies and catalogue, with links checked before delivery.
- One read-only lookup, such as order status, behind server-side authorization.
- Hand-over to a person for everything outside the agreed question types.
- One channel, usually the web chat, and one language to start.
Left for a later phase, priced separately: write actions such as refunds or address changes, more channels such as WhatsApp or Instagram, and further languages or markets.
What you receive at the end: the assistant on the agreed channel, the evaluation cases with their results, the hand-over rules, operating notes on what is monitored and what to check after a change, and a list of known limitations and open decisions.
A quote for workflow automation has the same shape, with journeys and syncs in place of question types; the Marketing automation and customer journeys page describes that work.
Request a scope-based estimate
Send a short workflow description, the systems involved, an approximate workload and your target outcome. I can help identify what an implementation quote needs to include.
Updated 6 October 2026.