The customer said yes on a Tuesday.

The money arrived sixty-one days later.

Nobody in the business can tell you exactly why.

If you own a small business or run a nonprofit, you know this feeling. The work gets done. The customers are happy. And the cash still shows up later than it should — late enough that you check the bank balance before payroll, late enough that you put off buying the equipment you already justified.

The usual explanation is “customers pay slow.”

That’s rarely the whole story. Most of the delay happens inside your own walls, and it’s invisible because nobody has ever drawn it.

So let’s draw it.

This is a process model — a picture of how one piece of work actually moves from start to finish, including the parts nobody writes down. Some people know this technique as process mapping; same idea. I wrote about the general method in an earlier post. This time, instead of explaining the technique, I want to apply it to one real process end to end and show you what falls out.

The process: from “customer says yes” to “money in the bank.”

Every business has a version of it. Almost nobody has looked at theirs.

The business

Picture a three-person landscape design and installation company. An owner who sells and designs, and a two-person crew. A typical job runs about $6,800.

The details below are a composite, but every step in it comes from real businesses I’ve sat with. If you swap “crew” for “caseworker” or “designer” or “instructor,” the shape holds.

What actually happens

Here is the real sequence for one job, with real elapsed time. Not the version in anyone’s head — the version you get when you trace a specific job, day by day.

Day 0. The customer says yes on the phone. The owner has the estimate in a field notebook.

Day 3. The owner retypes the notebook estimate into a written proposal, at the kitchen table, after dinner. Proposals only get written in the evening, because daytime belongs to job sites. Sends it by email.

Day 8. The signed agreement comes back — after the owner remembered, on Friday, to send a nudge. Nothing prompted the nudge except memory.

Day 11. The crew starts. The three-day gap was scheduling: the crew was finishing another job, and the calendar lives in the owner’s phone.

Day 13. The work is done. Two and a half days of actual labor. Mid-job, the customer asked for an extra planting bed — agreed to by text message, price confirmed nowhere.

Day 30. The owner assembles the invoice. Why day 30? Because invoicing happens at month-end, in one batch, because that’s when the owner “does the books.” Assembling this invoice means: reading the crew’s hours off a paper timesheet, re-reading the proposal, scrolling back through three weeks of texts to find the planting-bed change, and retyping all of it into the invoicing program. Ninety minutes for this one job. The invoice goes out day 31, terms net 30.

Day 40. The customer emails: what is this $740 line item? It’s the planting bed. The text message never made it onto anything the customer could see, so the invoice is the first written record — and it reads like a surprise.

Day 43. The owner finds the text thread, screenshots it, replies. The customer says: got it, check is going out.

Day 57. The check arrives in the mail.

Day 61. The owner deposits it — bank runs happen when the owner is already in town — and matches it to the invoice in the books that weekend.

Money in the bank, sixty-one days after yes.

The model

Drawn as a flow, with the waiting made visible:

flowchart TD
    yes["Customer says yes (day 0)"] -->|3 days waiting| proposal["Owner retypes notes into a proposal"]
    proposal -->|5 days waiting| signed["Customer signs the agreement"]
    signed -->|3 days waiting| work["Crew performs the work (2.5 days)"]
    work -->|17 days waiting| invoice["Owner assembles the invoice at month-end"]
    invoice -->|10 days waiting| question["Customer questions one line item"]
    question --> reply["Owner digs through texts, replies"]
    reply -->|14 days waiting| check["Check arrives in the mail"]
    check -->|4 days waiting| bank["Deposited and recorded (day 61)"]

And as a ledger of working time versus waiting time:

Stage	Working time	Waiting time	What ends the wait
Proposal written and sent	45 min	3 days	Owner’s free evening
Agreement signed	10 min	5 days	Owner remembers to nudge
Work scheduled	—	3 days	Crew frees up
Work performed	2.5 days	—	—
Invoice assembled and sent	90 min	17 days	Month-end arrives
Customer reviews, questions a line	—	10 days	Customer gets around to it
Dispute answered	30 min	3 days	Owner finds the text thread
Check mailed and received	—	14 days	Postal service
Deposited and recorded	20 min	4 days	Owner’s next trip to town

Totals: about three days of actual work inside 58 days of waiting. Roughly fourteen steps, and the job changes hands eleven times — owner to customer, customer to owner, owner to crew, crew to owner, and around again.

Every one of those handoffs is a place where the job can sit. And in this business, the job only moves when one specific person — the owner — picks it up.

What the model reveals

None of this was secret. The owner lived every one of those days. But until it’s drawn, it’s a feeling. Drawn, it’s three specific flaws with price tags.

1. The same information is written down five times. Field notebook, proposal, agreement, timesheet, invoice. Each re-entry costs time, but that’s the small cost. The big cost is that each re-entry is a chance for the copies to disagree — and the planting-bed change that lived only in a text thread is exactly that. A customer who finds a surprise on an invoice stops paying and starts asking. The question took 13 days to raise and resolve. Re-entry doesn’t just waste minutes; it manufactures disputes, and disputes reset the payment clock.

2. Month-end batching quietly adds two weeks to every job. The work finished on day 13. The invoice went out on day 31. Batching feels efficient — do all the books at once — but the math is unforgiving: if you invoice once a month, the average job waits about two weeks after completion before the customer even knows what they owe. The customer’s net-30 clock doesn’t start when you finish the work. It starts when you ask. This business was extending an interest-free 17-day loan on every single job, as a side effect of a bookkeeping habit.

3. Nothing watches the waiting. Look at the “what ends the wait” column. Almost every entry is a person’s memory: the owner remembers to nudge, the owner remembers month-end, the customer gets around to it. No step has a deadline once it leaves the building. An unsigned agreement sitting in a customer’s inbox looks exactly like silence, and silence triggers nothing. The owner is not slow — the owner is the only alarm clock the process has, and an alarm clock that’s also running job sites, writing proposals, and driving to the bank misses.

That’s the answer to “why is cash late.” Not slow customers. Fifty-eight days of unwatched waiting, punctured by three days of work.

Should be

Now the interesting move: redesign nothing. Buy nothing. Just run the existing process the way everyone already assumes it runs.

The proposal goes out the day after yes, because proposal-writing gets a standing hour on the calendar instead of waiting for a free evening. The nudge on an unsigned agreement happens on day three, every time, as a rule rather than a memory. Changes agreed mid-job get written on the job ticket the same day, and the customer initials it — thirty seconds with a clipboard. The invoice goes out the day the crew finishes, because “we invoice on completion” replaces “we invoice at month-end.” Unpaid invoices get a reminder at day 14 and day 25, as policy.

Same people, same paperwork, same tools. The sixty-one days becomes roughly thirty: mostly the customer’s genuine net-30 window, with almost nothing added on top of it.

That’s a month of cash-flow improvement on every job, and the total cost was writing five rules down. Most process problems die right here, at “should be.” You cannot get here without the model, though — the rules only became obvious once the waiting was visible.

Could be

Then there’s what today’s tools make possible, honestly scoped.

The proposal, agreement, invoice, and payment can live in one place, so information is entered once and flows forward. The customer signs on a screen, and the signature itself schedules the job. The invoice carries a payment link, which replaces two weeks of check-in-the-mail with two minutes. Reminders send themselves on a schedule nobody has to remember. The deposit matches itself to the invoice in the books.

And yes, there is a place for AI in this — a narrow, unglamorous one. It can draft the proposal from a photo of the field notebook, for the owner to correct rather than compose. It can pull the planting-bed change out of the text thread and put it on the job ticket, so the change order stops living in someone’s pocket. It can notice that the draft invoice doesn’t match the signed agreement before the customer does.

Notice what AI is doing there: retyping, searching, and cross-checking. The drudgery has names, and it removes the named drudgery. It does not know your customer, price your work, or decide what fair looks like. Anyone selling it as the hero of this story hasn’t drawn the story.

The honest sequence is: model first, fix the rules second, add tools third. A tool bolted onto the sixty-one-day version of this process would have automated the waiting.

The real point

You cannot automate a process you cannot see. You cannot delegate it either — “just handle invoicing” fails when invoicing is actually eleven handoffs and a text thread. And you certainly cannot improve it, because you’ll fix the step that annoys you instead of the wait that costs you.

One more thing, and it matters more than any diagram.

The people who do the work have to be in the room when the model is drawn. The crew knows the timesheet is wrong by Wednesday. The owner’s spouse knows which customers need two nudges. When those people trace the process themselves and spot the seventeen-day gap with their own eyes, the fix is theirs, and it sticks. When an outside expert presents the same finding as a breakthrough, it gets a polite nod and dies in a drawer.

The model is cheap. A wall, some paper, the people who live the process, and one honest question: what actually happened on the last job, day by day?

Draw yours. Count the working days and the waiting days. I’d be surprised if the ratio is better than one to ten — and once you can see it, you can change it.

If you’d like help modeling a process in your business or organization — with your team in the room — get in touch or take a look at coaching, where this kind of working session is a regular part of the work.

A Process Model of Getting Paid