Worked example

Quote to invoice, without the retyping

One job's details, typed into four systems by four different people, over eleven days. This is the shape of workflow problem we see most often, and what actually changes when it is fixed.

This is an illustration, not a client story. It is assembled from the pattern that recurs across small field-service businesses rather than describing one company, because we are not going to invent a testimonial and attach a logo to it. The workflow, the failure points and the numbers are realistic; the company is not real. Every figure below is an illustration of the pattern rather than a projection of what you would save, which depends entirely on your own volumes. When we have a client case study to publish, it will say so and it will name them.

The business

A commercial HVAC contractor. Eleven staff: two in the office, seven engineers in vans, an owner who still quotes the larger jobs, and a bookkeeper two days a week. Around forty jobs a month, average invoice a little over two thousand dollars.

They run good software. That is the point worth noticing: nothing here is broken, and no tool in the stack is a bad choice.

QuotesA spreadsheet the owner has refined over nine years. It prices jobs better than any package they have tried.

SchedulingA field-service app the engineers use on their phones. Good at dispatch and photos.

AccountingQuickBooks, which the bookkeeper knows and the accountant expects.

CustomersA CRM the owner bought two years ago and half-populated.

What happens to one job

Follow a single boiler replacement through the week, and the same nine facts get typed in four times.

The current path

Day 1. Enquiry arrives by phone. Office manager writes it on a pad, then types the customer into the CRM.
Day 2. Owner prices it in the spreadsheet, retyping the address and contact from the CRM. Saves a PDF, attaches it to an email.
Day 5. Customer accepts by replying to the email. Nobody updates the CRM, because the reply went to the owner's inbox.
Day 6. Office manager creates the job in the scheduling app, retyping the address, the contact and the scope of works from the PDF.
Day 8. Engineer completes the job, adds photos and two extra parts on his phone.
Day 11. Bookkeeper opens the scheduling app and the quote side by side, works out what changed, and types the invoice into QuickBooks by hand.

Nobody is doing anything wrong. Every step is a reasonable thing for a person to do given the step before it. That is exactly why it survives for years.

What it costs

The re-entry itself is roughly twenty minutes per job. Across forty jobs, that is about thirteen hours a month, or a little over three thousand dollars a year in office time. Annoying, but on its own it would not justify a project.

The expensive part is the second-order effects, which nobody bills for and everybody absorbs.

Invoices sent lateDay 11 rather than day 8, because invoicing waits for the bookkeeper's next day in. Three days of cash flow on every job, permanently.

Parts not billedThe two extra parts the engineer added are on his phone, not on the quote. When the bookkeeper is busy, they are sometimes missed. At two or three jobs a month, that is real money.

A stale CRMBecause acceptances arrive by email and never make it back, the CRM does not know which quotes were won. So nobody trusts it, so nobody updates it, so it gets worse.

Nobody can answer"Where is that job up to?" requires opening three systems. The office manager becomes the only person who knows, and cannot take a holiday without a handover document.

What we would automate, and what we would not

The instinct is to replace all four tools with one platform. We would advise against it. The spreadsheet prices jobs better than the packages do, the engineers already use the scheduling app without complaint, and the accountant wants QuickBooks. Replacing working tools to fix a data-transfer problem is solving the wrong problem at ten times the price.

What is actually broken is the space between them.

The build

One place a job starts. A short form for the enquiry, feeding the CRM directly, so the pad and the first retype both disappear.
Quotes pull from the CRM. The spreadsheet stays exactly as it is. It reads the customer and address rather than having them typed in again.
Acceptance updates everything. The quote goes out with an accept button rather than as an email attachment. Accepting marks the CRM won and creates the scheduled job, with the address and scope already filled.
Completion drafts the invoice. When the engineer marks the job done, the quoted lines plus anything he added become a draft invoice in QuickBooks.
A weekly exception report. Jobs completed but not invoiced, quotes older than fourteen days with no answer, invoices past thirty days.

The invoice stays a draft. A person reviews and sends it. That is deliberate: sending money requests to customers automatically is exactly the kind of irreversible step that should wait for a human, and the review takes two minutes rather than twenty.

What changes

Re-entryNine facts typed once instead of four times. About thirteen hours a month back.

Invoice timingDay 8 or 9 instead of day 11, and it no longer waits for the bookkeeper's day in.

Missed partsWhatever the engineer records is on the draft. Not because people were careless before, but because it is no longer a separate act of remembering.

The CRMKnows what was won and lost, without anyone maintaining it. Which is the only way a CRM in a business this size ever stays current.

What it does not fix

Worth being straight about, because a page like this usually is not.

It does not make anyone quote faster. Pricing a job is judgement, and the owner is still the one doing it.
It does not fix the CRM's existing data. Two years of half-populated records stay half-populated. New jobs are clean; the back catalogue needs a decision about whether it is worth the cleanup.
It adds a dependency. Four systems that talk to each other can break in ways four systems that ignore each other cannot. That is what the exception report and the monitoring are for, and it is a real trade rather than a free win.
It will need attention when a vendor changes an API. Not often, but not never.

Shape of the work

ScopeFixed price agreed before starting, from a written description of the current path like the one above.

SequenceThe invoice draft first, because it carries most of the value and proves the connection works before more is built on it.

Where it runsTheir accounts, their API keys, their data. Nothing routes through us.

HandoverSource, documentation, and a session walking through what breaks and how to tell.

The first question we would actually ask is not about software. It is whether the twenty minutes and the three-day delay are worth what the fix costs. Sometimes they are not, and for a business doing twelve jobs a month rather than forty they usually are not. That answer is free, and we would rather give it than take the work.

Recognise your own week in this? Describe the path a job takes through your systems and roughly how many times a month it happens. You will get a straight answer on whether it is worth connecting them, and a rough number, usually within one business day.

Get your free review

Home Workflow & integration Build example Terms otr-world@pm.me