Somebody describes a workflow on a call. Forty minutes later a number comes back with a delivery date attached. The number is wrong and it is wrong in one direction, because it was priced against the version of the workflow that works.
That is not dishonesty. It is what happens when you estimate from a description. Ask anyone to explain how their team handles invoice approval and you get the path that runs correctly, because that is the path they can describe. The branches where it does not run correctly are the ones nobody narrates: the supplier who sends a spreadsheet instead of a PDF, the approver on holiday, the request that arrives against a closed project code. Those branches are the build. The happy path is a fraction of the code and almost none of the testing.
So the honest answer to "what will this cost" before scoping is a range wide enough to be useless. The useful answer is to price the scoping separately and quote the build against what it finds.
What actually makes a workflow expensive
Three things move the number more than anything else, and none of them are the model or the volume.
System count, and identity between systems. Each additional system is another set of credentials, another rate limit, another pagination scheme, another data model that disagrees with the last one, and a sandbox that may not exist. Read access in a demo is the easy half. Write access with someone accountable for it is a procurement conversation.
The part that quietly doubles a build is identity. The same customer is a record in the CRM, a different id in the billing system, an email address in the shared inbox, and a spelling in a spreadsheet. If there is a shared key, the mapping is a day of work. If there is not, you are building a matching layer with its own tolerance rules, its own exception queue, and its own review, and that layer is a project rather than a task. Ask early whether the systems agree on who the customer is. The answer usually surprises the people inside the company.
How reversible the action is. An agent that drafts is cheap. An agent that sends is expensive. An agent that posts to a ledger is expensive and slow.
The question is what undo costs. A draft sitting in a folder costs nothing to discard, so the pass mark can be loose and the testing short. An external email cannot be recalled, which buys you an approval step, a release queue, and a much harder argument about the error rate you accept. A posted journal needs a reversal path, an audit trail with a name against every action, and sign-off from a controller who is right to be suspicious of you. Same agent, same model, three different builds. Tell whoever is quoting which of the three you want, because assuming the cheap one is how a quote comes in low.
The exception rate. The exception path is most of the work. Even at two percent you still build the whole apparatus: the queue, the reasons, the routing, the way an item re-enters the flow after a human decides, the report that shows the rate is not drifting. Almost none of that cost scales down with the rate.
It does scale up, though, and there is a level at which you should not build. If a quarter of items need human judgement, an agent removes some reading and leaves the expensive part untouched, and what the process needs is a fix upstream in how work arrives. A good audit tells you that and talks you out of the build. Nobody can tell you that from a description, because the exception rate is not something teams know about themselves. They have a feeling, and the feeling is always optimistic.
Two more that show up in the estimate
Whether the system has a usable API decides a lot. If the answer is no, you are on a browser driver or a scheduled file exchange, and both work, and both are fragile in ways that need monitoring and a person who gets paged. Add real time for that rather than hoping the vendor ships an API this year.
Data history matters too. An agent applying rules to five years of inconsistently entered records spends its first weeks on cleanup that nobody scoped. Ask what changed in the last three years: a system migration, a new chart of accounts, a rebrand that renamed every product. Each of those is a seam in the data, and rules have to handle both sides of it.
Buy the audit as its own thing
The way out of this is to buy the scoping work as a separate, finished deliverable with its own fixed fee, and no obligation to buy anything afterwards. That structure is not a sales tactic. It is the only shape that lets the audit come back with bad news.
Fixed fee works here because the scope is knowable in advance. A defined number of interviews, a defined set of systems, a written document at the end. Ours runs ten working days and produces a page per workflow with hours and cost against each one, then a ranked build order with the first workflow specified tightly enough to quote. Any competent version of it will look similar.
Judge the audit on whether it counts or estimates. Volumes read out of the systems are worth something. Volumes people remembered in a meeting are not, and the gap between the two is routinely large in both directions. Ask what the exception rate was in the sample. Ask which workflows the audit recommends leaving alone, and treat a list with nothing on it as a bad sign, because a firm that finds every workflow suitable was shopping rather than measuring.
Price the walk-away so it is real. If stopping after the audit means losing a deposit or paying a penalty, the audit is a sales document with a fee attached. You should be able to take the document, thank everyone, and implement it with your own team or a cheaper firm. That is what makes the recommendations trustworthy.
If you already have a fixed-price quote
You may have one anyway, and sometimes a fixed price after proper scoping is exactly right. Ask two questions before signing.
First, what happens if the exception rate turns out to be triple what was assumed. If the answer is a change order, the quote is a starting number and you should plan for the range. If the answer is that it is absorbed, ask what gets cut to absorb it, and know the answer: testing, the exception queue, and the handover. That is the actual mechanism by which a low fixed price becomes a system people switch off in month four.
Second, what is explicitly out of scope. A short out-of-scope list means nobody has looked hard. A long one, naming specific edge cases and specific systems, means somebody has, and that is worth paying more for.
The number you want is not the lowest. It is the one that survives contact with your real data, quoted by somebody who has looked at it. Ten days of looking is cheap compared to a build scoped from a conversation.