One mistake companies make when evaluating AI is starting the cost conversation too low in the stack.
It is natural to ask how much the model call costs, how many tokens are being used, whether the prompt can be shortened, or whether a cheaper model would work. Those are all legitimate questions. They matter, especially once usage starts to scale. But they are not the right first questions.
A more useful starting point is the workflow. What work is being done today? Who is doing it? How often does it happen? How long does it take? Where does it break down? What happens when it is delayed, inconsistent, or wrong?
That shift matters because the company is already paying for the workflow — it just does not show up on an AI invoice. The cost is in employee time, slow handoffs, rework, customer delays, and the organizational drag of routing every ambiguous decision through the same person. The real comparison is AI-enabled workflow versus the current workflow, not AI cost versus no cost.
Why token-level analysis can mislead
Token-level analysis can be misleading because it makes the AI usage look precise before the business problem is clear. You can know that a model call costs a few cents and still have no idea whether the system is worth building. A cheap model call attached to an unimportant workflow is still waste. It can be technically impressive and produce a decent answer. But if it does not improve work that matters, the return is probably small.
On the other hand, a model call that looks expensive in isolation can be very inexpensive relative to the workflow it improves. If an AI-enabled process costs $20 or $40 a week but saves five hours of experienced employee time, helps the team move faster, and reduces repeated mistakes, the model cost is probably not the main issue. What matters is not whether the AI call is cheap — it is what work the AI call is improving, and what that work costs today.
Example 1: Customer support
A token-level analysis of customer support focuses on the cost of generating a response: how long is the prompt, how much context is being sent, which model should draft the answer. Those are useful implementation questions, but they are not enough.
A workflow-level analysis starts earlier and ends later. How does the customer request arrive? What kind of issue is it — billing, a product problem, an account issue, a shipping delay, a technical bug? What context does the support person need to answer well, and where does that context live? In the CRM, order history, product documentation, previous tickets, Slack, internal notes, or someone's head?
Ask those questions and you find that the expensive part of the workflow is not writing the response. It is gathering enough context to know what the response should be. AI is useful in several places: classifying the request, gathering relevant customer history, summarizing previous interactions, surfacing the relevant documentation, and drafting a response for a human to review. The value is that the support person starts with better context, newer team members operate more consistently, and customers get answers that are less dependent on who happened to pick up the ticket. That only becomes legible when you compare AI cost against the full workflow cost — time spent searching, delay in response, inconsistent answers, escalations, rework, and missed learning from customer patterns.
Example 2: Sales preparation
Before a sales call, someone looks through the CRM, reads prior notes, reviews the prospect's website, checks past interactions, and prepares a useful agenda. A token-level lens asks how much it costs to generate a pre-call summary. What actually matters is what the current preparation workflow looks like.
Is every salesperson preparing consistently? Are they spending 20 minutes before every call trying to assemble context? Are some people skipping preparation because they are busy? Are good discovery questions being reused across the team? Are lessons from past calls improving sales motion, or disappearing into scattered notes? An AI-enabled workflow that prepares a first-pass account brief — summarizing prior interactions, identifying likely pain points, drafting discovery questions, flagging missing information — does not replace the salesperson's judgment. It gives them a better starting point.
The business case is not that the summary costs X cents. The business case is that the team has ten sales calls a week, preparation quality varies, each rep spends time reconstructing context, and better preparation could improve the quality of discovery and follow-up. The model call is one small part of the economics.
Example 3: Founder and executive bottlenecks
This shows up a lot in smaller companies and early-stage teams. The founder becomes the system. A customer asks something unusual, so the founder gets pulled in. A developer needs clarification, so the founder makes the call. Marketing wants to know how to position something, so the founder explains it again. An investor update needs to be written, so the founder reconstructs what happened over the last month. None of those interactions look huge individually, but together they create a drag on the organization — the founder or executive becomes the routing layer for ambiguity.
Token-level analysis misses almost everything important here. The question is not how much it would cost to summarize a Slack thread or draft a decision brief. The real question is why decisions and context keep routing through one person. Sometimes the answer is that the team lacks a shared operating system: priorities are not clear, product decisions are not captured, customer feedback is scattered, strategy lives in conversations rather than usable artifacts, and people are not sure what they can decide without approval.
In that environment, AI can help, but only if it is attached to workflow design. An AI-enabled workflow could turn meeting notes into decision logs, summarize open questions, draft follow-up tasks, organize customer feedback by theme, or prepare weekly leadership briefs — helping the founder review and correct the system rather than recreate it every day. If that saves three to five hours a week and helps the team make better decisions without waiting, the token cost is not the interesting part of the analysis. The interesting question is whether the workflow became more trustworthy.
Example 4: Product feedback and prioritization
Most companies have more feedback than they can use well. It comes from support tickets, sales calls, customer success notes, onboarding calls, cancellation reasons, feature requests, and informal conversations. The problem is rarely that no one has feedback. The problem is that the feedback is scattered, inconsistent, and hard to turn into decisions.
A token-level analysis asks what it costs to summarize a batch of customer comments. A workflow-level analysis asks what happens to feedback after it is received: where does it go, who reads it, how is it categorized, how does the product team distinguish a loud customer from a common pattern, how are repeated issues surfaced, how do sales and support know whether something is already planned or still being evaluated? An AI-enabled workflow that summarizes feedback, tags it by theme, connects it to accounts or revenue segments, and produces a weekly product brief does not make the product decision. It improves the inputs to the decision. The value is that the organization sees patterns sooner, prioritizes with better evidence, and closes the loop with customer-facing teams — not that summarization got cheaper.
Start with the work, not the model
Good candidates for AI-enabled workflow redesign share a few traits: the work happens repeatedly, it requires judgment, the context is scattered, and the output quality depends on who does it. There is also often a bottleneck around one or two experienced people who become the default path for anything ambiguous.
But AI may be part of the answer, not the whole answer. You still need to understand the process, define ownership, decide where human review belongs, determine what good looks like, and measure whether the new version is better than the old version. Without that framing, AI can make a messy workflow move faster — and faster mess is not progress.
Optimize after the workflow proves value
None of this means token costs are irrelevant. Once you know a workflow is valuable, optimization makes sense: smaller models for simpler steps, separated classification from reasoning, cached repeated context, reduced prompt size, improved retrieval, routing different tasks to different models based on complexity. But that optimization should come after workflow clarity. Otherwise, teams spend too much energy shaving pennies off usage before they have proven that the workflow matters.
The order should be: understand the work being done today, estimate what that work costs in time, delay, quality, rework, and attention, identify where AI could improve the path from input to outcome, build a small version of the workflow, measure whether the work is actually better, then optimize the model, prompt, retrieval, routing, latency, and cost structure.
The better question
The question is not just how much a model call costs. What actually needs an answer is what work is being changed — how often it happens, who does it today, how long it takes, where it breaks down, what poor execution costs, and what would improve if the workflow were faster, clearer, or more consistent. Once you understand that, token costs can be evaluated in the right context — and not before.