The short answer: A supplier can't honestly price an agent before seeing the process, because most of the cost sits in your systems, your data and the points where your people check the work, and little of it in the AI. Ask instead for a small, fixed-price first step that looks at one process and returns a written design, a fixed price for the build and an estimate of the monthly running cost. Then you're comparing documents, and no longer comparing guesses.
"Roughly how much would it cost?" is a fair question, and the usual reply, "it depends", is an irritating one. This article explains what it depends on, what goes wrong when someone gives you a number anyway, and what to ask for so that you get a figure you can hold a supplier to.
You won't find a price in it. Any figure I gave here would be a blind quote, and that would undo the argument.
Where the cost sits
The model at the centre of an agent is the part every supplier buys in. It's bought by usage, it's much the same whoever builds your system, and it's rarely where the building work goes. The work goes into everything around it, and that part is different for every business.
- Your systems. What does the agent have to read from and write to? Does each system offer a supported way in, or does someone have to build one? Connecting to one modern system is a small job. Connecting to an old one with no supported route can be most of the project.
- Your data. Where does the material live, what state is it in, and who is allowed to see it? Documents in one tidy folder cost little to work with. The same information spread across inboxes, scanned letters and a spreadsheet only one person understands costs a good deal more.
- Your review points. Wherever a person checks the work, somebody has to build what that person sees: the result, the evidence for it, and a way to approve, correct or reject it. More checks mean more to build, and so does a higher standard of evidence.
- Your exceptions. The usual case is quick to build. The cost is in the awkward cases, and only your staff know how many there are.
- Your tests. To show that the thing works, a supplier needs real examples with known right answers. If you have them, testing is quick. If they have to be assembled, that's work too.
None of this can be seen from a phone call. It's like asking a builder to price an extension without visiting the house: the bricks cost the same everywhere, and the price is in the ground and the drains.
What a blind quote costs you
A supplier who quotes without looking has three options, and you pay for each of them.
- Pad it. The price includes a margin for everything that might be lurking in your systems. If your systems turn out to be tidy, you've overpaid.
- Quote low and vary it later. The first figure wins the work. Then the old system, the scanned letters and the awkward cases come to light, and each one arrives as a change request.
- Quote for something smaller than you need. The price covers a demonstration that works on sample data and isn't connected to anything. Connecting it is "phase two".
There's a fourth cost. You can't compare two blind quotes, because each supplier has priced a different project of their own imagining. The cheaper one may simply have imagined less.
What to ask for instead
Ask for a small first step, at a fixed price, that covers one process and ends with three things in writing.
- A written design. What the software will do and what it won't. What it reads from and writes to. Where people check its work and what they'll see when they do. How you'll both know it works.
- A fixed price for the build. A price for building what the design describes, with a plain statement of what would change it.
- An estimated monthly running cost. A figure with its assumptions written beside it, above all the volume of work it's based on.
To produce those, the supplier has to sit with the people who do the job, see the systems and read real examples, which is the looking that a phone call can't do.
Three things make this worth paying for. It's small, so the risk is small. The documents are yours, and you can take them to another supplier for a second price. And you learn how the supplier works before you've committed to the larger sum.
How we start
Our own work begins on paper. As our How we build page says, work starts as a written design, then a specification and a plan, and only then is it built. When someone brings us a process and it's a fit, we suggest a small first piece of work. And we won't promise numbers we haven't measured on your work.
What pushes the price up or down
| Lower price | Higher price | |
|---|---|---|
| Systems to connect | One, with a supported way in | Several, or one with no supported route |
| Material | Digital, in one place | On paper, scanned or scattered |
| Rules | Written down | In people's heads, with many exceptions |
| Review | One existing check | Several new ones, each needing a screen |
| Cost of a mistake | Stays inside the business | Reaches a customer or a regulator |
| Examples for testing | Already collected | Have to be assembled |
| Who uses it | One team, one way of working | Several teams with different rules |
| Where data must be held | No special requirement | Strict requirements |
Most of the left-hand column is in your hands. Our article on choosing a first process is, among other things, a guide to choosing a cheap one.
The two bills
There are two bills, and blind quotes usually mention only the first.
The build, which you pay once.
The running cost, which you pay every month for as long as you use the thing. It has three parts:
- Model usage. This is usually charged by the amount of text the model reads and writes, so it rises with the number of cases and the length of the documents. It's the part that changes if your volume doubles.
- Hosting. The servers the software runs on, and the storage for its records and logs.
- Upkeep. The systems the agent connects to will change, and so will your rules and the models themselves. Someone has to watch that it still works, fix it when it doesn't, and re-test it after each change.
Ask for the running estimate at your real volume, and ask what it would be at double. Ask who pays the model usage: you directly, or the supplier, who passes it on. And ask what upkeep covers, because "support" can mean anything from answering the phone to rebuilding a connection when your accounts package changes.
On our side, we run and maintain what we build, on the same infrastructure we use for our own products.
Questions to ask any supplier
- Will you look at the process before you quote, and what will I have in writing afterwards?
- Is the build price fixed? What would change it?
- What will it cost to run each month at our volume, and what is that estimate based on?
- Who pays for model usage, and can we see that bill?
- Where is our data held, and who can see it?
- Where do our people check the work, and can those points be moved later?
- What does it record about what it did?
- How will we know it works, and whose examples is it tested on?
- Who maintains it, and what does that cover?
- What do we own at the end, and could another supplier take it over?
- Which of your own processes do you run this way?
A supplier who has done the work before will have ready answers to most of these. Take long pauses as information.