Blog

They signed. Everybody was pleased.

Three weeks later they are finally set up and working properly. In between: an account created here, a login sent there, documents chased twice, a form filled in that asked for things they had already sent, and one thing that got missed and surfaced in week four.

The selling took a week. The starting took three. And the second one is the bit the customer will remember when they describe you to somebody else.

Where the three weeks go

Onboarding is the most system-heavy process in most businesses, because it is the one moment when every system needs to learn about the same person at once.

• Details, collected more than once. They gave you their information when they enquired, again on the contract, and again on the setup form. Three times, because none of those three places talk to each other.
• Documents, chased. Identification, insurance, a signed authority, whatever your trade requires. Somebody asks, waits, asks again, and holds the mental list of who owes what.
• Accounts, created by hand. Your job system, your accounting package, your portal, your scheduling tool. Each one a separate person doing a separate manual creation.
• Access, sent piecemeal. Logins arriving in separate emails over days, some of which go to spam and get resent.
• The internal handover. Sales knows things that operations needs and passes them on in a conversation, which means whatever was not said is now lost.
• The thing nobody owns. One step sits between two people’s jobs. It gets done late or not at all, and surfaces as a problem a month later.

The cost is not the admin hours

Count the hours by all means. They are real. But three other costs are larger.

Revenue starts late. Whatever they signed for is not running yet, so nothing is being delivered or billed. Multiply the delay by what a customer is worth per week and you have a number that dwarfs the admin.

First impressions are load-bearing. The onboarding is the first time they experience how you actually operate, rather than how you sell. A chaotic three weeks teaches them something about you that a good sales conversation cannot undo.

The thing that gets missed. Every manual onboarding has a step that occasionally does not happen — a permission not granted, a document never collected, a system where they were never created. It is not discovered on day one. It is discovered on the day it matters.

Why this stays manual longer than anything else

Two honest reasons, and it is worth knowing them before assuming it is neglect.

First, it feels like a one-off. Every new customer feels bespoke while you are in it, so it never quite gets treated as a repeatable process even when it is the ninetieth time.

Second, it genuinely crosses the most boundaries. Onboarding touches sales, operations, finance and whatever compliance your trade has. Processes that cross departments have no single owner, and a process with no owner does not get improved. It gets endured, and everybody assumes somebody else finds it as annoying as they do.

What an Onboarding Engine does with it

The shape: new customer, documents, accounts, running.

One intake that collects everything once. A checklist that exists in the system rather than in someone’s head, so what is outstanding is a fact anybody can look up rather than a thing somebody remembers. Chasing that happens on a schedule without a person deciding to do it. Accounts created from the details already held rather than re-typed. And a visible state — which stage this customer is at, what is blocking them, how long they have been waiting.

The gates stay yours. Approving the customer, checking their documents are genuinely acceptable, deciding an exception is fine — all human. What goes is the collecting, the re-typing, the remembering and the chasing.

What I saw doing this from the other side

At Pantheon I delivered platform training to customers’ development teams, which meant meeting a lot of organisations at exactly this stage — after the decision, before things worked.

The pattern I would hand you: the customers who struggled later were almost always the ones whose start was messy, and not because the mess caused the problems. It was that a chaotic onboarding meant nobody had a complete picture of what that customer actually had, so every later question started with an investigation.

The setup is not admin you get through before the real relationship starts. It is where the record of the relationship gets created, and a bad one costs you for as long as they stay.

Audit your own, this month

• Take your last five new customers. Write the date they committed and the date they were genuinely up and running.
• Write the gap. Then ask each internal person involved what they were waiting on.
• Count how many times the customer supplied the same information. Ask them if you dare — it is the most useful uncomfortable question available.
• List every account or access that has to be created. Mark who creates each and whether anything verifies it happened.
• Find the step with no owner. There is one. Ask two people who does it and see whether the answers match.

If your gap is a day or two, nobody re-supplies anything, and every step has a name against it — you have a working onboarding, and it is rarer than you think.

What to do next

Measure the gap on your last five customers, and ask how many times each supplied the same information. Those two numbers describe your onboarding more honestly than any process document.

If your checklist lives in someone’s head, the difference between a checklist and an engine is where to look next.

If you want the whole picture instead of one workflow: tell us what’s still manual. You get a map of every point where your business stops and waits for a person, what that costs you in hours, and which of those an engine would take over first. Free, yours to keep, and useful even if you never hire us — including on the days the honest answer is that you should not build anything yet.

Common questions

Our onboarding genuinely is different for every customer. Does this still apply?

The steps vary; the skeleton rarely does. Nearly every onboarding is collect information, verify documents, create access, hand over internally, confirm running — with different content in each box. Build the skeleton and let the contents vary. If the honest answer is that two customers share nothing at all, you are doing bespoke projects rather than onboarding, and that is a different process.

How do we handle customers who are slow to send documents?

Separate your delay from theirs before you fix anything, because they need opposite treatments. Track the two clocks separately — time waiting on us, time waiting on them. Most businesses discover their own delay is bigger than they assumed. For the customer side, scheduled chasing that happens without anyone deciding to do it outperforms a person who feels awkward about nagging.

Is it worth automating if we only onboard a few customers a month?

For hours saved, frequently not. For the step that gets missed, sometimes yes — and that is the honest way to weigh it. Low volume is exactly where manual processes drift, because nobody does it often enough to build the habit. If your risk is a compliance step being skipped rather than time, the value is in the checklist existing outside somebody’s memory, and that is cheap to build.

What about the internal handover from sales to operations?

That is where most of the loss is, and it is the least automated part of any onboarding. Everything the salesperson learned lives in their head and their inbox, and gets passed on in a conversation. Anything not said in that conversation is gone. Capturing it at the point of sale, in a structure, is unglamorous and pays for itself faster than anything else here.

Monday morning. Somebody exports three files, opens a spreadsheet, does the joining by hand, fixes the two rows that never match, and produces the numbers you look at.

They have done this every Monday for two years. It takes most of the morning. Nobody has ever put it on a job description and nobody could stop doing it without you noticing immediately.

The gap nobody names

Your systems hold enormous amounts of data. Your accounting package knows what was invoiced. Your scheduler knows what was booked. Your job system knows what got done. Your inbox knows what customers asked for.

None of them hold the answer, because the answer needs two or three of them at once. What did we actually earn per job last month, by type? Which customers are slower to pay than they used to be? How many jobs went out without being invoiced?

Every one of those questions is a joining problem across systems that were never introduced. So a person becomes the join. Every recurring report in your business is somebody doing by hand what the systems could not do to each other.

Four costs, and the last one is the real one

The morning. Obvious, measurable, and the smallest of the four. Count the hours and multiply.

The staleness. A report built weekly is a picture of last week. You are steering on a delay, and the delay is invisible because the numbers still look current when you read them.

The single point of failure. One person knows which files, which columns, which two rows always need fixing, and which number is wrong in a way you have all agreed to ignore. When they are away, the report does not happen or happens badly.

The questions nobody asks. This is the expensive one. When getting an answer costs half a day of someone’s time, you stop asking the interesting questions. You only ask for the standard report — so the one-off question that would have shown you something useful never gets asked at all. The cost of a manual report is not the morning. It is every question that was not worth the morning.

The dangerous version: when the spreadsheet becomes the system

There is a stage past this that is worth naming, because it creeps up.

The report starts as a summary. Then someone adds a column that is not in any system — a status, a note, a manual correction. Then somebody else starts reading that column to make decisions. Now the spreadsheet is not reporting on your business. It is holding part of your business, and it lives in one file, on one machine, with no record of who changed what.

If any recurring spreadsheet in your business contains information that exists nowhere else, that is not a reporting problem any more. That is an operational system with no backup and no audit trail, and it deserves to be treated as one.

What a Report Engine does differently

The shape: Monday’s numbers, already assembled, nobody built them.

Instead of a person gathering from three systems on a schedule, the engine keeps the join up to date continuously. The report is not produced on Monday — it is simply always current, and Monday is just when you happen to look.

Two things follow that are worth more than the saved morning. Asking a new question becomes cheap, so you start asking them. And the numbers stop depending on one person’s undocumented process, which means they survive holidays and resignations.

What I learned watching systems get monitored properly

At Pantheon I worked on platform operations for sites that could not go down, which meant a lot of time around monitoring — the discipline of knowing what is true right now rather than what was true when somebody last looked.

Here is the transferable part, and it took me longer to internalise than it should have. The value of monitoring was almost never the dashboard. It was that questions became cheap. When finding out costs nothing, you check things you would never have bothered to check, and that is where the useful surprises came from — not from the metric somebody thought to put on the wall.

Your Monday report is the opposite arrangement. It answers one fixed question expensively, which guarantees you only ever ask that one.

Find out what yours costs

• List every recurring report somebody produces by hand — weekly, monthly, for you, for the accountant, for a customer.
• For each, write who makes it and how long it takes. Ask them; do not estimate on their behalf.
• Ask each one what breaks in their process — the rows that never match, the manual fix, the column that lives nowhere else. Write those down. That list is the actual specification.
• Count the systems each report joins. One system is a reporting feature you may already own. Three systems is a joining problem.
• Ask yourself the honest one: what would you check weekly if checking cost nothing? If you have a list, you have already found the value.

If your reports come out of one system, take ten minutes, and nobody would miss anything if they stopped — leave this alone entirely. Not every business has this problem.

What to do next

List your recurring manual reports and ask each person what breaks in their process. That list of quiet fixes is the specification, and it is the thing nobody ever writes down.

Then ask what you would check weekly if checking cost nothing. If the dashboard you already own is not being opened, the reason is worth understanding.

If you want the whole picture instead of one workflow: tell us what’s still manual. You get a map of every point where your business stops and waits for a person, what that costs you in hours, and which of those an engine would take over first. Free, yours to keep, and useful even if you never hire us — including on the days the honest answer is that you should not build anything yet.

Common questions

Couldn’t we fix this with a reporting tool bolted onto our systems?

Sometimes, and it is the cheaper thing to try first. If your data is mostly in one system and it has decent reporting, use that. Reporting tools struggle in exactly the place manual reports exist — where the join is across systems, and where the joining requires business rules like which job counts as which type. The rules are the hard part, not the chart.

Our data is messy. Doesn’t that have to be fixed first?

It has to be faced, not necessarily fixed first, and the distinction saves a lot of stalled projects. The manual report already handles the mess — someone fixes the same two rows every week. Those fixes are the rules, and writing them down is most of the work. What you should refuse is a system that silently guesses; the mess should be visible and flagged, not smoothed over.

How do we know the automated numbers are right?

Run both for a while and compare, which is the only answer that should satisfy you. Keep the manual report going alongside the automated one for a few cycles and check them against each other. Where they disagree, one of them is wrong and finding out which teaches you something either way — frequently that the manual one had a quiet error nobody had caught.

What if the person who builds the report is worried about their job?

That is a reasonable worry and worth answering directly rather than reassuring vaguely. The honest framing is that the half-day is being removed, not the person — and the interesting work, which is interpreting the numbers and acting on them, is what they have never had time for. If the real answer is that the role was only the report, say so honestly rather than discovering it later.

You are looking at quoting software because your quotes take too long and look inconsistent. Fair. It will help.

Before you buy, here is the distinction that decides whether you get what you are hoping for: quoting software makes writing a quote faster. It does not make quotes happen.

If your problem is the writing, buy it today. If your problem is everything around the writing, you will be disappointed in about six weeks, and it will not be the software’s fault.

What quoting software genuinely fixes

Real value, and worth naming properly rather than dismissing.

• The document looks professional and looks the same every time, whoever produced it.
• Line items and pricing come from a list rather than someone’s memory, so the arithmetic stops being a source of errors.
• Templates cut the typing on the jobs you do repeatedly.
• The customer can accept online, which removes a genuine stop — the printed, signed, scanned, emailed loop.
• You have a record of what was quoted, at what price, to whom.

That last one is undervalued. A searchable history of what you charged and who accepted is a pricing asset, and most businesses do not have it.

What it does not do

All of these remain exactly as they were the day before you bought it.

• It does not start. Nothing happens until a person opens it and begins a quote. The inquiry that arrived at 7pm still sits there.
• It does not gather. The customer’s details, the site information, the previous job, the measurements — someone still collects those from four places and types them in.
• It does not decide who prices this. If one person handles the complicated ones, the quote still waits for them.
• It does not chase. Some tools send a reminder on a schedule, which helps. Almost none of them know that this customer replied with a question three days ago and the thread went cold.
• It does not notice absence. An inquiry that never became a quote leaves no record in a quoting tool, because a quote was never created.

Which is the general shape of the thing: a better place to write a quote is still a place someone has to go.

What a Quote Engine does instead

Same job, different shape. Rather than a place you go, it is a path the work travels: request arrives, gets priced, gets sent, gets chased, gets decided.

Concretely, that means the inquiry is read wherever it lands and the details are pulled out of it. The standard lines get priced from your own rules. Anything unusual is flagged rather than guessed. A complete draft is waiting for you with one or two things marked as needing your call. You decide, it sends. Then it chases on its own schedule, notices replies, and tells you when a quote has gone quiet.

The thing to notice: the pricing judgement never left you. What left is the gathering, the typing, the remembering and the chasing.

The honest decision

Two questions settle this without anyone selling you anything.

First: when your quotes are slow, is the delay in the writing or before it? Take your three slowest recent quotes and find where the time actually went. If most of it was after someone sat down to write, software fixes it. If most of it was before — waiting to be noticed, waiting for details, waiting for the person who prices this — software will not touch it.

Second: what happens to a quote after it is sent? If the honest answer involves the word “remembers”, you have a chasing problem, and a document tool has no view of it.

Why I am not going to tell you to buy the bigger thing

I spent years as a project manager writing scopes and quotes, and I have been the bottleneck in exactly this process, so I want to be straight about where the line falls.

Plenty of businesses genuinely have a document problem. Their quotes are slow because producing the document is a forty-minute job in a word processor with manual arithmetic and a logo that never sits right. For them, quoting software is the correct purchase, it costs very little, and a build would be spending thousands to feel organised.

The reason to be careful is the opposite case, which is more common and less obvious. The tool gets bought, the document gets better, and the three-day delay does not move — because the delay was never in the document. Then the conclusion drawn is that automation does not work here, when what actually happened is that the wrong stop was removed.

Find the stop first. Then buy whatever removes that one.

Check yours in an afternoon

• Take your last ten quotes. Write down when the request arrived, when someone started writing, when it was sent.
• Split the total delay into “before writing” and “writing”. Compare the two totals.
• Count how many pieces of information had to be gathered from elsewhere before writing could start.
• Check the chase: of those ten, how many were followed up, and was it on a schedule or by memory?
• Count the ones that never became quotes at all. If you cannot, that gap is its own answer.

What to do next

Split your last ten quotes into delay-before-writing and delay-during-writing this afternoon. That single split tells you which purchase would actually change your number.

If the delay is before, the anatomy of the three days breaks down each stop. If you want the cost side, what a Quote Engine replaces works through the arithmetic.

If you want the whole picture instead of one workflow: tell us what’s still manual. You get a map of every point where your business stops and waits for a person, what that costs you in hours, and which of those an engine would take over first. Free, yours to keep, and useful even if you never hire us — including on the days the honest answer is that you should not build anything yet.

Common questions

Can we start with quoting software and build later if it doesn’t help?

Yes, and it is frequently the right sequence — it is cheap, it is quick, and it produces the pricing history that makes a later build better informed. Ask one question before you commit: how do we get our data out. A quoting tool holds your pricing record, and you want that portable long before you have any intention of moving.

Our pricing is genuinely complex. Can any of this be automated?

The complexity is usually less uniform than it feels from the inside. Most quotes turn out to be mostly repeatable lines plus one or two genuine calls, and the useful split is exactly there: the repeatable part is assembled for you, the calls are flagged and left to you. If a system tries to make the judgement calls, that is the part to refuse.

How do we handle quotes that need a site visit before pricing?

The site visit stays — nothing here removes going to look at the job. What changes is everything around it: the visit gets scheduled from the inquiry rather than after a phone tag exchange, and what you record on site becomes the quote rather than notes you type up that evening. The visit is the value; the double-handling around it is not.

What if the win rate on fast quotes is the same as slow ones?

Then you have learned something genuinely valuable and you should not spend money on speed. It happens — in some trades the buyer is comparing detail over weeks and being first buys nothing. Measure your own before assuming; the answer varies enormously and everybody assumes theirs is the urgent kind.

A customer emails with a problem. Before anybody can help them, someone has to read it.

Read it, work out what they actually mean, decide whether it is urgent, decide who in the business handles this, check whether they have written before, find their order, and only then start on the actual answer.

All of that happens before a single useful word gets written back. And it happens on every message, every time, from scratch.

The reading is the job

Count what a support message needs before a reply exists.

• Comprehension. What is this person asking? Frequently not what the subject line says.
• Classification. Is this a fault, a question, a complaint, a chase, or someone in the wrong place entirely?
• Urgency. Is anything actually broken right now, or does this read urgent because the customer is annoyed?
• Context. Who are they, what did they buy, what happened last time, is there an open job?
• Routing. Who in the business can answer this, and are they available?

Five judgements, most of them mechanical, all of them done by a person with the rest of their day waiting. On a busy morning the reading queue itself becomes the bottleneck — and a queue that is backed up on reading looks identical to a queue that is backed up on hard problems.

What it costs when reading is the bottleneck

Three things, and the third is the one that damages you quietly.

Response time goes up on everything. Including the messages that would have taken thirty seconds to answer, because they are sitting behind messages that need thought.

Easy things get expensive. The person doing the reading is frequently your most experienced person, because they are the only one who can tell what matters. So your most expensive hour is spent sorting.

The queue stops being visible. When reading is slow, nobody actually knows what is in the queue — only what has been read so far. Ask what is waiting and the honest answer is a guess. That is how a genuinely urgent message sits for a day among sixty routine ones.

Where a person genuinely has to stay

Worth being clear about, because the wrong version of this idea is a chatbot answering customers on its own, and that is a liability with a friendly tone.

The judgement stays with your team. What the customer is told, what gets refunded, what gets promised, what an unhappy person hears from you — those are decisions with consequences and they belong to a human.

The sorting is not judgement. Working out that this message is a delivery question about order such-and-such from a customer who wrote twice last week is not a decision. It is retrieval, and it is exactly what should arrive already done.

The useful shape is: everything is read, classified, routed, and drafted — and then it stops and waits for you. You read a prepared reply and a summary rather than a raw message and a blank box. You still decide every single one. You just stop doing the assembly first.

Fifteen years of queues, and what I would tell you

I started on a service desk in 2006 and ended up running the technical support team at Pantheon, a platform hosting sites that could not go down. That is a lot of mornings opening a queue and feeling the day’s shape in the first five minutes.

Here is the thing that would have saved me the most time, offered so you do not need the fifteen years. The cost was never the hard tickets. Hard tickets are the job and they are satisfying. The cost was the constant re-orientation — picking up something with no context, reconstructing who this was and what happened, then putting it down to do it again on the next one.

Fifty messages a day, three minutes each of reconstruction, is two and a half hours of somebody’s day spent getting back up to speed. Nobody ever billed for that or noticed it. Run the same arithmetic on your own volume and you will get a number that is uncomfortably specific.

Measure your own reading cost

• For one week, log the time between a message arriving and someone first opening it. Not answering — opening. That gap is your reading backlog.
• Sort last month’s messages into five buckets using the list above. If one bucket is enormous and routine, that is your candidate for going first.
• Count how many needed context from elsewhere — an order number, a past conversation, a job record — before anyone could reply.
• Ask who does the reading and what their hourly cost is. Then ask what they were hired to do.
• Check the tail. Of last month’s messages, how many took more than three days? Read those five specifically and ask what stalled them. It is rarely difficulty.

If your first-open time is minutes, your buckets are evenly mixed, and nothing tails off — you have a healthy queue and a well-staffed team. Genuinely leave it alone.

What to do next

Measure your first-open time for one week. That single number tells you whether your queue is slow because the work is hard or slow because nobody has read it yet — and the two problems have completely different fixes.

If the sorting is your cost, the comparison with a help-desk tool covers who drafts and who approves. For the wider count, map the stops across the flow.

If you want the whole picture instead of one workflow: tell us what’s still manual. You get a map of every point where your business stops and waits for a person, what that costs you in hours, and which of those an engine would take over first. Free, yours to keep, and useful even if you never hire us — including on the days the honest answer is that you should not build anything yet.

Common questions

Isn’t this just an argument for a help-desk tool?

A help-desk tool is a real improvement on a shared inbox and worth having, so if you do not have one, start there. What it gives you is a place where tickets have owners, statuses and history. What it does not do is read the message, work out what it means, pull in the customer’s context, or draft anything. It organises the queue — somebody still works it.

Won’t customers be able to tell if a reply was drafted automatically?

They can tell when nobody read it, which is a different thing. A draft that has been reviewed and sent by a person who knows the customer reads like a person, because one was involved at the point that matters. The failure mode people recognise instantly is the generic reply that did not engage with what they asked — and that failure comes from rushing, not from drafting.

Our volume is low. Is this worth thinking about?

At low volume the cost is not hours, it is interruption, and that is worth measuring differently. Twelve messages a day scattered across the day can break up the work of your best person more expensively than forty batched ones. If the honest answer is that support is a small, calm part of the week, leave it alone.

What happens when something genuinely unusual arrives?

It should be flagged as unusual rather than forced into a bucket, and that is a design question worth asking anyone who proposes this. A system that is confident about everything is more dangerous than one that says it is unsure and hands the odd one to a person. The weird ones are exactly where human judgement earns its money.

“Custom software” is a frightening phrase, and it should be. It sounds like a blank page, an open-ended bill, and a thing you cannot picture until it either works or does not.

So here is the part nobody explains before you have already signed something. An engine that runs a business process is not a blank page. It is assembled from six parts, and it is the same six every time.

Knowing them is useful even if you never buy anything, because it gives you six specific things to ask about instead of nodding along to a demo.

The six

• The intake. Where work comes in — a form, an email, an upload, a phone call, a message from another system. One door, so nothing arrives somewhere nobody is watching.
• The router. Decides where each thing goes. Is this urgent, is it a warranty job, is it a customer we already have, does it need the person who handles the tricky ones.
• The workers. The steps that actually do it — read the document, pull the fields, price the lines, build the record, send the thing.
• The gate. Where it stops and asks you. The one place a human decision is genuinely required, with everything already prepared.
• The log. Everything it did, in order, replayable. What came in, what it decided, what it sent, who approved it and when.
• The panel. Where you watch it run. How many times it ran this week, how many it handled alone, how many it stopped for you.

Why this matters commercially

Because it answers the question that decides whether you are being quoted for a project or a product: is this off-the-shelf or bespoke?

The honest answer is both, in a specific way. The parts are standard. The wiring is yours.

The intake, the router, the gate, the log and the panel are the same machinery for a plumbing firm as for an accountancy practice. What differs is what the workers do and where the gates sit — and that is the part that has to be built around how you actually run. It is why an engine takes weeks rather than months, and it is also why nobody can hand you one out of a box.

The two parts people skip, and what it costs

If you look at a proposal and only four of the six are described, it is almost always these two that are missing.

The log. Skipping it is invisible on day one and expensive on the first bad day. Without a record of what the system did and why, a disputed invoice, a missing order or a wrong decision becomes an argument rather than a lookup. Ask to see the log before you agree to anything — not a description of it, the actual screen.

The panel. This is the one you touch daily, and it is the difference between owning something and hoping something is happening. Not a business dashboard full of charts. An engine dashboard: it ran this many times, it handled this many on its own, it stopped for you this many times.

That last one deserves emphasis because it is a trust instrument as much as a feature. A number you can look at every morning is what stops an automated process from being a black box you are afraid to touch.

The gate is the part that decides whether you can trust it

Every fear people have about automating operations lives in one question: what if it does something stupid at scale?

The gate is the answer. Money, records, permissions and anything a customer sees are exactly where a person stays in the loop. The engine does the assembly and stops; you decide; it continues. It proposes, you dispose, every run is logged.

Which also means a proposal that describes no gates at all is not a more advanced system. It is one where nobody has thought about what happens on the day it is wrong.

Why I care about the log more than most people

I build open-source tooling for governing AI agents in my own time — the main one is a kernel that judges work by evidence and executable checks rather than by how confident a model sounds, and it is genuinely pre-release, with known gaps written down in its own README rather than hidden.

The thing that project taught me transfers directly here, so take it and skip my version of learning it. Absence of evidence has to be a failure, not a default pass. A system that cannot show you what it did should be treated as a system that did not do it — because the alternative is trusting a report instead of checking an artefact, and reports are where the expensive surprises hide.

That is not a technical preference. It is the same instinct that makes you keep receipts.

Use the six as a checklist

Take whatever you are being sold — a build, a platform, an automation project — and ask one question per part.

• Intake: what are all the ways work can arrive, and does every one of them land here?
• Router: what decides where something goes, and can I change that rule without calling you?
• Workers: which steps run without a person, and which still need one?
• Gate: where does it stop and ask me, and what does my screen show at that moment?
• Log: show me the record of one run, end to end, right now.
• Panel: what do I look at on a Monday morning, and what does it tell me in one glance?

Any of those six that comes back vague is not necessarily a dealbreaker. It is a thing to get specific in writing before money moves.

What to do next

Take the six-part checklist into your next proposal conversation and ask one question per part. The two that come back thinnest are where your risk is.

The gate is the part worth understanding first — where your engine stops and asks you covers how to place it. If you have not mapped your process yet, start by counting the stops.

If you want the whole picture instead of one workflow: tell us what’s still manual. You get a map of every point where your business stops and waits for a person, what that costs you in hours, and which of those an engine would take over first. Free, yours to keep, and useful even if you never hire us — including on the days the honest answer is that you should not build anything yet.

Common questions

Does every process need all six parts?

Every process that runs on its own does, though some parts get small. A simple flow might have one intake, no real routing, two workers, one gate and a minimal panel — but it still needs the log, and it still needs somewhere you look to know it is alive. What varies is the size of each part, not whether it exists.

Can we build this on top of the systems we already pay for?

Usually, and that is normally the cheaper and better answer. The workers frequently are your existing systems — your accounting package, your scheduler, your email — with the engine moving work between them and holding the state. Anyone whose first proposal is to replace everything you own should have to explain why, specifically, rather than as a general principle.

Who owns the engine and everything in it?

You should, from day one, and this is worth settling in writing before any work starts rather than at handover. Credentials in your name, accounts in your company’s name, the code in a repository you control. The test is simple: if you fired the builder tomorrow, could the next person take over what exists without asking permission from anyone?

How long does something like this take?

Weeks rather than months for a single process, precisely because five of the six parts are not being invented each time. The variable is how much has to be mapped first and how many external systems have to be connected — connecting to a modern system with a documented interface is fast, and connecting to something old or closed can take longer than the rest of the build.

Someone wanted to give you money on Tuesday evening. They filled in your form, or emailed, or messaged the page, or rang and left a voicemail.

Nobody answered until Thursday. By Thursday they had already spoken to someone else.

You will never know that happened. There is no report anywhere in your business that lists the customers you lost by being slow, which is exactly why this problem survives in businesses that are otherwise run tightly.

Inquiries arrive in more places than anyone thinks

Write down every route by which a stranger can reach you. Be thorough and slightly uncomfortable about it.

• The contact form on the site
• The general email address
• Someone’s individual work email, because that is who they met once
• The phone, in hours
• The phone, out of hours, into a voicemail box someone checks eventually
• Messages on whichever social pages you keep
• A message to a staff member’s personal phone, because they gave a customer their number to be helpful
• Walk-ins and people asking at a counter
• Whichever directory or marketplace you are listed on, with its own inbox nobody has logged into since setup

Most businesses find seven or eight routes. Then ask which of those has a person definitely responsible for it, by name, today. The gap between those two lists is your leak.

Why nobody notices

Every other problem in a business announces itself. A late job gets a phone call. A wrong invoice gets a complaint. A broken system gets shouted about.

A missed inquiry does nothing. The person quietly goes elsewhere and does not tell you why, and your inbox looks exactly the same as it would on a good week.

This is the same failure that makes silent problems so expensive everywhere else: absence produces no signal. Nothing arrives to tell you that nothing arrived. Which means the only way to see it is to go looking on purpose.

The other half: the ones that were answered badly

The inquiries you did answer have their own losses, and they are more measurable.

Someone replies to say they have received it and will get back. Someone else has to work out what the customer actually wants. A third person turns out to be the one who handles jobs like that. By the time a real answer goes out, three people have touched it and a day has gone.

None of that is bad service. It is a routing problem being solved by hand, every single time, from scratch. Routing is the most automatable thing in your entire business and it is almost always done by a human reading and forwarding.

What five years on a service desk taught me about this

I started on service desks in 2006 and spent years there before moving on, then ran a support team at Pantheon later. The queue was the job, so here is what I would want to know if I were you.

The thing that made a queue healthy was never how fast people typed. It was whether every arriving thing landed in one place with a name attached to it within minutes. Where that was true, a busy day was tiring and fine. Where it was not, work fell through gaps that nobody could later reconstruct — and the reconstruction attempt was always worse than the original loss, because now you have also lost the trust.

The uncomfortable part: on the desks where things went missing, everybody was working hard. Effort was never the variable. The variable was whether the arrival had an owner before a human decided it did.

Find your own leak this week

• List every route in, including the awkward ones — personal phones, old marketplace inboxes, the address on a business card printed in 2019.
• For each, name the person responsible. If you cannot name one, that route has no owner and is where things go.
• Send yourself a test inquiry down every route. All of them, on a normal working day, and see what happens and how long it takes. This takes an hour and it is the most informative hour you will spend this month.
• Do it again at 7pm on a Friday. The difference between the two results is your out-of-hours exposure.
• Count last month’s inquiries against last month’s quotes. If you cannot produce the first number at all, that is the finding.

If every route has an owner, every test came back within the hour, and you can produce both counts — genuinely, you are fine. Go and count a different flow, and do not let anyone sell you a fix for this one.

What to do next

Send yourself a test inquiry down every route this week, once in hours and once on a Friday evening. The results are frequently uncomfortable and always specific.

If routing is where yours falls over, the comparison with a chatbot covers what happens after an inquiry is qualified — which is where most of the loss actually is.

If you want the whole picture instead of one workflow: tell us what’s still manual. You get a map of every point where your business stops and waits for a person, what that costs you in hours, and which of those an engine would take over first. Free, yours to keep, and useful even if you never hire us — including on the days the honest answer is that you should not build anything yet.

Common questions

Would an auto-reply solve most of this?

It solves the customer’s anxiety and none of your loss, which is worth being clear-eyed about. An automatic acknowledgement buys goodwill and time, and it is cheap, so send one. What it does not do is get the inquiry to the right person or make sure anyone acts on it. If the auto-reply is the whole system, you have automated the reassurance and left the work where it was.

How fast do we actually need to respond?

Ask your own lost customers rather than a benchmark. Call five people who enquired and did not buy, and ask when they decided and who they went with. Their answers give you the real window, and it varies hugely — an emergency trade call is a different race from a considered purchase. Measuring your own is worth more than any published average.

We’re a small team. Isn’t a shared inbox enough?

It can be, if two things are true: every route feeds into it, and every arriving item gets an owner rather than sitting in a pile everyone can see and nobody holds. Shared inboxes fail in a specific way — the diffusion of responsibility means a message read by four people can be actioned by none. If yours has assignment and you use it, that is a real system.

What about the inquiries we never see because we’re not found at all?

That is a genuinely different problem and it is not one we work on — how customers find you is marketing, and Anito builds engines for how the work gets done once it arrives. Worth separating the two before you spend money, because they have completely different fixes and it is easy to buy one while suffering from the other.

You are getting three quotes. They all demo well. Two of them are within a few thousand of each other and the third is half the price.

You cannot judge the code and nobody expects you to. But you can judge the answers.

Here is the thing a demo can never show you. A demo shows the part that works — the happy path, the screen where everything goes right. The money dies in the other twenty percent: what happens when two people click at once, when a payment provider is down, when someone types something ridiculous, when it is three in the morning and nobody is watching.

These eight questions go straight there. Ask them in the room. You are not marking the answer. You are watching the shape of it.

The eight

• 1. What happens if this runs twice? Systems retry. Networks hiccup. If the answer involves a shrug, ask what happens if a customer is charged twice, or an order ships twice.
• 2. Show me where it breaks. What is the worst thing someone could type in? Every real builder has a list. It is usually funny and very specific.
• 3. Who can log in and see everything? Show me that screen. Not a description of permissions. The screen.
• 4. What happens when the payment provider or the email service is down? Not if. They all go down. The question is whether your work is lost or held.
• 5. If I fire you tomorrow, what does the next person need? Show me it exists. Existing, today, not promised at handover.
• 6. How will I know it’s working at 3am when nobody’s watching? Silence should not be the only signal that things are fine.
• 7. What did you decide not to build, and why?
• 8. Restore the backup. Not take one — restore one, in front of me.

How to read the answers

You do not need to evaluate the technical content. There is a pattern in the delivery that is far more reliable, and once you have seen it you cannot unsee it.

A real answer gets shorter and more specific. It names a thing. A screen, a file, a failure, a decision. It frequently includes a small admission — “that one bit is ugly”, “we handle that badly at the moment, here is the plan.”

A bluff gets longer, warmer and more confident. It reassures. It talks about experience, process and best practice. It never contains a specific failure, a specific screen, or a specific file.

Listen for length. That is genuinely most of it.

Question 7 is the one that ends it

If you only ask one, ask what they decided not to build.

Every engineer who has actually made a system work has a list of things they refused, and can say why in one sentence: it would have doubled the timeline for a feature two people would use; it would have made the data model unable to change later; the client wanted it and it would have made the thing slower for everyone.

Somebody who has never made an engineering trade-off has no list. They will say they build whatever you need. That sounds like great service and it is a red flag, because a project where nothing was ever refused is a project where nothing was ever weighed.

Question 8 is the one nobody expects

Everybody takes backups. Almost nobody has watched one come back.

A backup that has never been restored is a belief, not a safety net. The restore is where you find out that the file was empty, the process needs a password nobody has, or it takes eleven hours and the business cannot be down for eleven hours.

Asking to see a restore is not aggressive. Any team that has been through a real outage will find it a completely reasonable request, and some of them will look pleased that you asked.

Why I trust this test

I spent four years running a technical support team at Pantheon, a hosting platform for sites that could not go down, and five years before that on service desks. That is a long time hearing people explain systems under pressure, and it is where the length-of-answer pattern comes from — not from a book.

The engineers who had actually built the thing answered in fragments and specifics. The ones who had not talked in paragraphs about the general shape of things. The confident, warm, unspecific answer was the tell every single time, and it took me an embarrassing number of tickets to notice it consciously.

I have also been on the wrong side of it. I built a hosting control panel fast, with an AI agent doing the typing, and I would have answered question 6 with something vague and cheerful. Then hours went into bugs that should not have existed, and the agent kept reporting success while nothing worked. Better prompts did not fix it. Intelligence bolted onto a bad structure is not intelligence — it is faster chaos. Question 6 would have caught me.

Using these without being difficult

• Send them in advance if you want considered answers rather than a performance. The ones who prepare properly will thank you.
• Ask all eight of every quote, including the one you already like. Especially that one.
• Write down the answers, not your impression of them. Impressions are what good salespeople manage.
• Ask a follow-up on anything longer than a paragraph. “Can you give me the specific example?” Silence after that question is data.
• Do not penalise an honest gap. “We do not do that well yet, and here is what we would do instead” is a better answer than a confident yes.

Nothing here requires you to become technical. It requires you to notice what a specific answer sounds like — and you already know that, from every other trade you have ever hired.

What to do next

Take these into your next quoting conversation. Write the answers down as they are given rather than your impression afterwards, and ask a follow-up on anything that runs long.

If you want to arrive with more than questions, map where your work stops first — a quote answered against a described process beats one answered against a wish.

If you want the whole picture instead of one workflow: tell us what’s still manual. You get a map of every point where your business stops and waits for a person, what that costs you in hours, and which of those an engine would take over first. Free, yours to keep, and useful even if you never hire us — including on the days the honest answer is that you should not build anything yet.

Common questions

Won’t asking these make me look like I don’t trust them?

It has the opposite effect on the people worth hiring. A team that has cleaned up after a bad build will read these as a client who is going to be reasonable when something goes wrong. If someone is offended by being asked what happens when their email provider is down, you have learned something valuable for the price of a slightly awkward moment.

What if all three quotes answer badly?

Then you have learned something real about your shortlist and you should widen it rather than pick the least bad. It also happens that a small shop answers well on some and honestly badly on others — that combination is frequently the best available option, because the honest gap is the part they will tell you about later too.

Do these apply to no-code and off-the-shelf builds?

Most of them, with small rewording. Questions 1, 4, 5, 6 and 8 apply to anything that runs your operations regardless of how it was assembled. If the answer to 5 is that the whole thing lives inside one person’s personal account on a platform, that is exactly the situation the question exists to surface.

Is the cheapest quote always the risky one?

No, and assuming so costs people money. A low quote can mean a smaller scope honestly described, a template approach that genuinely fits, or someone who works efficiently. What matters is whether the difference is explained. Ask what the low quote leaves out and compare that answer to the other two — the gap is usually in exactly the twenty percent these questions are about.

A supplier sends you an invoice. It arrives in under a second.

Eight days later it is in your accounting system. Somewhere in between, it was a PDF in an inbox, a forwarded email, a printout on a desk, a line typed by hand, and a question about which job it belonged to.

Nothing about that week was anybody’s fault, and all of it was expensive.

The eight days, broken down

Trace one invoice backwards and the pattern is the same in nearly every business that has not deliberately fixed it.

• It lands in an inbox that is not a queue. Invoices arrive in the same place as newsletters, customer replies and internal chatter. There is no list of what is outstanding, so the only record of what has arrived is whether somebody remembers seeing it.
• It waits to be read by a person. Somebody opens the PDF and pulls out the supplier, the date, the total, the tax, the reference. Every one of those numbers is already written down. They get typed again.
• It waits to be coded. Which job? Which cost centre? That question frequently needs the person who ordered the thing, and that person is on site.
• It waits for approval. Someone has to say yes. The saying takes seconds; the getting-round-to-it takes days.
• It waits to be entered. The details get typed a second time, into the accounting system this time.
• Then somebody chases the ones that never arrived at all.

Six stops. And the last one is the one that should worry you most, because it is the only one with no evidence trail. An invoice that never arrived leaves no trace anywhere in your process.

What the delay actually costs

Three costs, and only one of them is obvious.

The typing. Count your invoices per month and multiply by an honest estimate of minutes each — reading, coding, entering, filing. Do that arithmetic with your own numbers and it usually lands somewhere between a day and a week of someone’s month.

The early-payment discounts you did not take. If any of your suppliers offer terms for paying early, an eight-day internal delay eats the window before anyone has decided anything. That is money left on a table nobody is looking at.

The picture being out of date. This is the one that matters. If invoices reach your books a week late, then every figure you look at is a week stale, and you are making decisions about cash on a picture of last Tuesday. Not wrong exactly — just always behind, in a way that is invisible because the numbers still look authoritative.

The document is messy, and that is the actual problem

Here is why this has stayed manual longer than most office work.

Every supplier’s invoice looks different. The total is in a different place, the tax is broken out differently, the reference number is called something else, and one supplier sends a photo of a docket taken at an angle. A human handles that variety without thinking about it. Software historically could not.

That has genuinely changed, and it is worth knowing what changed and what did not. Reading a messy document and pulling structured fields out of it is now something machines do well. Knowing whether the number it pulled is right is a different question, and that one still needs a person — which is exactly why the useful design is not “the computer does invoices” but “the computer does the reading and hands you the ones it is unsure about.”

What I learned typing other people’s numbers

I spent a stretch of my career as a database administrator and project manager, which meant a lot of hours reconciling records that disagreed with each other. Here is the part worth passing on, because it cost me time to learn.

The errors were almost never typos in the amount. People concentrate on the money. The errors were in the boring fields — the date, the reference, the job code — because attention had already been spent on the number that felt important. Then a month later something did not reconcile, and finding out why took an afternoon.

So if you are checking your own process, do not just spot-check totals. Check the fields nobody thinks are interesting. That is where the week you lose next quarter is being created right now.

Measure your own week

• Take twenty recent supplier invoices. For each, find the date the supplier issued it and the date it was entered into your books.
• Write the gap in days. Then look at the spread, not the average — the average hides the ones that took three weeks.
• For the three slowest, find where they sat. Inbox, desk, approval, entry. One stage will dominate.
• Count how many needed a question answered before they could be coded. That count is what a better intake step would collect at the door.
• Now the hard one: how would you know if an invoice never arrived? If the honest answer is that a supplier eventually calls, nothing in your process is watching for absence.

If your gap is one or two days across the board and nothing goes missing, you have a working process. Do not spend money on it. Go and measure something that is actually costing you.

What to do next

Measure the gap on twenty invoices this week. Look at the spread and find the stage that dominates — that stage is your whole problem, and it is usually smaller than the conversation around it.

If the reading step is where yours stalls, the honest comparison of document tools covers what machines do well and where a person is still required.

If you want the whole picture instead of one workflow: tell us what’s still manual. You get a map of every point where your business stops and waits for a person, what that costs you in hours, and which of those an engine would take over first. Free, yours to keep, and useful even if you never hire us — including on the days the honest answer is that you should not build anything yet.

Common questions

Can’t we just tell suppliers to send invoices to one dedicated address?

Yes, and do it — it is cheap and it helps. What it fixes is the arriving-in-the-wrong-place problem. What it does not fix is that the address is still an inbox rather than a queue: nothing is tracking which invoices are outstanding, which are waiting on a question, and which never came. A dedicated address is a good first move and a poor last one.

How accurate is automated reading of an invoice, honestly?

Good on clean documents and less good on photographed dockets, handwriting and unusual layouts — which is the correct way to think about it rather than as a single accuracy number. The design that matters is what happens when it is unsure. A system that gives you a confidence signal and routes the doubtful ones to a person is safe. One that quietly guesses and posts is not, and no accuracy figure makes that difference go away.

Our bookkeeper does this and does it well. Why change it?

Then the question is not quality, it is concentration and coverage. Ask what happens during the two weeks they are on leave, and ask how you would know today if an expected invoice never came. If both answers are comfortable, leave it alone. A good bookkeeper on a small volume is a genuinely fine answer.

What about approvals — doesn’t a machine approving payments sound risky?

It would be, which is why nothing here suggests it. Approving money is a decision that stays with a person, permanently. The work worth removing is everything that happens before the approval: reading the document, pulling the fields, matching it to a job, checking it against the order, and putting it in front of you complete. You approve. You just stop assembling.

You did the sensible thing. You noticed your team was copying information between systems, and you bought something to stop that — Zapier, Make, n8n, one of the builders inside a platform you already pay for.

It worked. Some of the copying stopped.

And now you have a canvas to maintain, a subscription to pay, and one person who understands the flows.

What these tools are genuinely good at

Let us be straight about this before the argument, because a fair comparison is more useful to you than a sales one.

Workflow builders are excellent at a specific job: when this happens over here, do that over there. A form submission becomes a row in a sheet. A payment creates a record. A file lands and a notification fires. That is real work, it is genuinely removed, and for a lot of small businesses a handful of those flows is the right answer and the whole answer.

If two systems need to stay in step and nothing else about your process is broken, buy the builder. Do not let anyone talk you into a project.

The four things a canvas does not do

The trouble starts when you ask it to run a process rather than connect two points.

• It does not own the whole path. A flow fires on a trigger and finishes. Nothing is watching the job from arrival to finished, so nothing can tell you a job is halfway through and stuck.
• It does not notice absence. This is the big one. A flow triggers when something happens. When the thing never happens — the file that did not arrive, the confirmation that never came back — there is no trigger, so there is no alert, and silence looks identical to success.
• It does not hold a decision. Real processes need to stop and ask a person, then continue with that answer. Builders can send an approval message, but the state of “waiting for Sarah, since Tuesday, on this specific job” is not something the canvas holds and shows you.
• It does not survive change on its own. A service updates its interface, a field gets renamed, an account expires. The flow breaks, and it breaks quietly, and it stays broken until somebody notices work stopped arriving.

The maintenance nobody quoted you

Count your flows. Then ask who checks them.

In most businesses that has an answer, and it is a name. One person built the flows, understands what connects to what, and gets asked when something looks wrong. They frequently did it as a favour, on top of their real job, because they were the one who was interested.

That is a genuine risk and it has nothing to do with their competence. It means your operations depend on one person’s memory of an undocumented diagram. Ask what happens the month they leave, and notice whether the answer is a plan or a wince.

None of that makes the tool bad. It makes it a tool: it sits there, it does nothing until somebody works inside it, and it hands the work of keeping it alive back to you.

A canvas is not an engine

The difference is not sophistication. It is shape.

A canvas is a place you go to build and maintain connections. An engine is the thing that runs the work: it picks a job up when it arrives, carries it the whole way, handles what it can handle, notices when something is missing, keeps a record of everything it did, and stops only where a person should genuinely decide — arriving with the answer already drafted.

Put plainly: we don’t sell you the canvas. The point is to hand you the running thing. A builder is a set of parts and the assembly is left to you. That is a completely legitimate product — it is just not the same product as the work being gone.

How to tell which one you actually need

Six questions. Answer them about your own setup and the answer falls out without anyone selling you anything.

• Do your flows connect two points, or run a process? Two points is builder territory. A process with stages, waits and approvals is not.
• If a record never arrived, how would you find out? If the honest answer is “a customer would tell us”, nothing is watching for absence.
• Can you see, right now, what is in progress and where it is stuck? Not the data in each system — the state of the work.
• Who fixes a broken flow, and how do they know it broke? If both answers are one name and “eventually”, that is your risk.
• How many of your flows exist to compensate for another flow? A patch on a patch is a sign the shape is wrong, not that you need a seventh flow.
• Could a new person understand the whole thing from what is written down? If it only exists on a canvas and in someone’s head, it is not documented.

Why I am careful about this argument

I use automation hard, including AI, and I have built exactly the sort of quick flow this piece is about. The version of this argument that says “no-code tools are bad” is wrong and I am not making it.

What I got burned by was different: I let a fast-moving setup run without any structure underneath it, on a hosting panel I was building with an AI agent doing the typing. It looked like it was working. Then hours disappeared into bugs that should not have existed, and the agent kept reporting success while the code kept not working. Better prompts did not fix it.

Intelligence bolted onto a bad structure is not intelligence. It is faster chaos. That is the same failure as forty flows on a canvas with nobody watching them — the speed is real and so is the mess, and the second one arrives later.

What to do next

Sort your flows into the two groups this week — point-to-point, and process-propping. Then count one flow at both ends and find out whether anything is going missing.

If the second group is where your problems live, the six parts of an engine describes what it takes to run a process end to end, and the gate covers the part that decides whether you can trust it.

If you want the whole picture instead of one workflow: tell us what’s still manual. You get a map of every point where your business stops and waits for a person, what that costs you in hours, and which of those an engine would take over first. Free, yours to keep, and useful even if you never hire us — including on the days the honest answer is that you should not build anything yet.

Common questions

So should we cancel our automation subscription?

Almost certainly not, and doing it as a first move would cost you working flows for no gain. The useful exercise is to sort your flows into ones that connect two points cleanly and ones that are propping up a process. The first group is fine where it is. The second group is where the maintenance and the silent failures live, and that is the part worth changing.

How do I find out if flows are failing silently right now?

Pick one flow and count both ends for a week. How many things should have gone in, and how many came out the other side? Do it by hand, from the source system rather than from the automation’s own log, because a flow that never triggered has nothing to report. A gap between the two numbers is your silent failure rate, and most people have never measured it.

Our builder has error notifications turned on. Isn’t that covered?

That covers errors, which is not the same as absence. An error notification fires when a step ran and failed. It cannot fire when nothing ran at all, because there was nothing to fail. Those are the failures that hurt, since they look exactly like a quiet day.

Is there a size of business where a canvas is genuinely enough?

Yes, and it is more common than anyone selling builds will tell you. If your volume is low, your flows number in single digits, the person who maintains them is you, and nothing you run would cause real damage by being a day late, a builder is the right tool and a build would be spending money to feel organised.

A customer asks what it would cost. Three days later, you send them a number.

Nobody in your business spent three days on it. The actual work — looking at the job, deciding the price, writing it down — took about twenty minutes. The other two days and seven hours, the quote was sitting somewhere.

Ask where, and you get a shrug and a reasonable answer: it has been busy. That answer is true and it is also the reason the same thing will happen next week.

Where the three days actually go

Follow one quote through your business and it stops in the same places every time.

• Waiting to be noticed. The request arrives in an inbox, a form, a voicemail, or a text to someone’s personal phone. It waits there until a human happens to look.
• Waiting for the details. Whoever picks it up does not have enough to price it, so they ask a question and wait for the answer.
• Waiting for the person who knows. One person can price a job like this. They are on site, in a meeting, or on leave.
• Waiting to be written up. The price is decided. Now somebody has to open the template, re-type the customer’s details, and put it into a document.
• Waiting for a check. It sits with you for approval, which takes ninety seconds of attention and half a day of elapsed time.

Five stops. Twenty minutes of work. Three days of calendar. That gap is not a performance problem — it is the shape of the process.

What each day of delay costs

Run this with your own figures. I am not going to hand you an industry statistic, because the only number that means anything here is yours.

Take the quotes you sent last month and split them into ones that went out same day and ones that took more than two days. Compare the win rates. Then ask the customers you lost when they made the decision — some of them will tell you they went with whoever answered first, and that answer will be uncomfortable and useful.

Then the second cost, which is the one people forget. Every quote sitting in the middle of that process is also occupying somebody’s memory. They are holding a mental list of what has gone out, what has not, and who needs chasing. That list is doing real damage to their week and it never appears anywhere as a cost.

The chase is a second job

The quote goes out. Then what?

In most businesses, then nothing, until somebody remembers. The follow-up on day three, the second one on day ten, the decision to give up around week three — all of it held by a person who is also doing their actual job.

Which means your win rate is partly a measure of how good one person’s memory was that month. When they are busy, quotes go cold that would have closed. Nobody sees it happen, because a quote that was never chased leaves no trace at all.

What quoting software fixes, and what it doesn’t

Worth being fair here. Quoting software genuinely helps with the writing-up stop — templates, line items, a tidy PDF, a customer who can accept online. If your only problem is that quotes look scrappy and take an hour to type, buy the software. It is cheap and it works.

What it does not do is start. It waits for someone to open it and begin a quote. It does not read the inquiry that arrived at 7pm, pull the customer’s details out of it, notice that this is the third time this customer has asked, price the standard parts, flag the one line that needs your judgement, and have a draft waiting when you sit down.

It is a better place to write a quote. It is still a place a person has to go.

What I learned writing quotes for a living

I spent years as a project manager writing scopes and quotes before I moved into architecture, so the three days is a process I have personally been the bottleneck in.

Here is the part that surprised me and might save you a wrong conclusion: I was not slow at pricing. I was slow at starting. Every quote required me to go and gather the same six things from four places before I could think about the number at all, and that gathering is what I put off. Once the information was in front of me the quote took minutes.

So if you are about to solve this by telling someone to be quicker, check first whether the delay is the thinking or the gathering. In my case, and in most cases I have looked at since, it was the gathering — and nobody has ever fixed a gathering problem by trying harder.

Find your own bottleneck this week

• Take the last ten quotes you sent. For each one, write the date the request arrived and the date the quote went out.
• For the three slowest, reconstruct the timeline — when did it get noticed, when was the price decided, when was it written, when was it sent.
• Mark which gap is biggest. It is usually the same gap for all three, and that is your bottleneck.
• Ask what information was missing at the point it stalled. That list is what an intake step would need to collect up front.
• Check the chase. Of those ten, how many were followed up at all, and by whom? If the honest answer is “whoever remembered”, you have found a second bottleneck downstream of the first.

If all ten went out the same day and every one was chased on schedule, you do not have a quoting problem. Go and count a different flow — and do not let anyone sell you a fix for a process that is already working.

What to do next

Reconstruct three timelines this week and find the gap. If it is gathering rather than deciding, no amount of pressure on the person doing it will change the number.

When you are ready to compare a tool against the thing that would actually remove the stops, the honest comparison is here. For the wider picture, count the stops across the whole flow.

If you want the whole picture instead of one workflow: tell us what’s still manual. You get a map of every point where your business stops and waits for a person, what that costs you in hours, and which of those an engine would take over first. Free, yours to keep, and useful even if you never hire us — including on the days the honest answer is that you should not build anything yet.

Common questions

Would hiring an admin fix this faster than software?

Sometimes, and it is a fair comparison to make honestly. A person can absolutely close the gathering gap, and if your volume is low that may be the cheaper answer this year. What a person does not do is scale without cost or remember perfectly on a bad week — you are buying capacity, not removing the stop. Price both against the same thing: the number of quotes per month and what each day of delay is worth to you.

Our quotes need judgement. Doesn’t that rule out automating them?

It rules out automating the judgement, which nobody should be trying to do anyway. Most quotes are not one decision — they are twenty pieces of assembly and one or two real calls. The assembly is what moves on its own: pulling details out of the inquiry, applying your standard rates, drafting the document. The judgement stays yours, arriving with everything already prepared.

How fast is fast enough?

Ask your own customers rather than trusting a benchmark. Call three people who chose someone else recently and ask when they decided. Their answers tell you the window you are actually competing in, and it varies enormously between trades and deal sizes. Speed matters far more on small, comparable jobs than on large ones where the buyer is comparing detail.

What happens to quote history if we change how this works?

Ask that question before you buy anything, because it is the one that gets discovered late. Your past quotes are a pricing record — what you charged, who accepted, what you discounted. Whoever proposes a change should say in writing where that history ends up and how you get it out again. If nobody can answer, that is information about the proposal.