Build it into the tools you already run

Why not a new app

A new app asks your people to change where they look. That is the most expensive thing you can ask of a busy team, more expensive than the software, because attention is the one thing a twelve-person company has no spare of.

Dana’s crews live in text messages. Her office manager lives in email and the accounting software. Her dispatcher lives in a calendar. None of them are going to open a fourth thing, and they should not have to.

So the estimate system, when it gets built, does not have a screen. A request comes in through the web form or a forwarded text. The system reads it, asks the customer the two missing questions by text, files the answers, and puts the job on the calendar the dispatcher already watches. Dana sees it as a draft estimate in the inbox she already reads, with the last similar job attached. She edits, she sends. Nobody logged into anything new.

That is what “built into your tools” means. Not integrated with. Inside.

Where the system lives

In most small businesses there are four places work already happens, and a system should attach to as many of them as the job needs and no more.

The inbox. Requests arrive here and answers leave here. A system that reads the inbox and drafts replies for you to send is the single most common build, because it removes the wait from Chapter II without changing anyone’s habit.

The calendar. Anything with a date belongs here, and the system should put it here rather than in its own list. If your dispatcher checks one calendar, the system writes to that calendar.

The thing you already call the CRM. For some businesses that is real software. For many it is a spreadsheet with customer names in it. Either way, that is where customer history lives, and a system reads from it rather than starting a second copy.

The shared drive. Photos, estimates, signed documents. A system that files these in the folder structure you already have saves an hour a week on its own and nobody notices it working, which is the goal.

Notice what is not on the list. A dashboard. A portal. A new place to check.

What it looks like when it runs

A system built this way is mostly invisible, so it is worth describing what the owner actually sees.

Dana’s Tuesday now starts with three draft estimates in her inbox, each with the customer’s answers and the closest past job attached. She reads them in ten minutes. Two she sends as-is. One she reprices, because the house is older than the form suggested, and that judgment is exactly the kind of thing that stays with her.

Later a text arrives from the dispatcher. It is not a question. It is a note that a crew got pulled onto an emergency and the afternoon has been reshuffled, and the reshuffle is already on the calendar. The system did the reshuffle within the rules Dana set in Chapter II. The dispatcher approved it. Dana is being told, not asked.

That is the shape of every good build. The work happens. The decisions that need you still reach you. The rest is a sentence in a message that you can read or ignore.

One real example, in outline

The first system I built this way was for a real estate litigation practice in California. The work that kept landing back on the partner’s desk was research: the same kinds of questions, answered from the same body of past rulings, every time a new matter came in.

The build lives inside the practice’s existing case software. A new matter arrives. The system reads it, finds the past rulings that bear on it, and drafts a memo the attorney reviews before anything leaves the building. It does not have its own app. Nobody at the firm changed how they open a file. The firm is not named here until they say so, so treat this as the shape rather than the proof.

The lesson carries to a plumbing company. The system is defined by the work, not by the industry, and it always lands in the tool the team already has open.

The approval line, in practice

The line from Chapter II becomes real here, and it shows up as one question the system asks of every action. Can this go, or does this wait?

Actions that can go, go, and leave a note. Actions that wait show up as a draft in the place you already look, with a one-line reason they are waiting. You approve by doing what you would have done anyway: sending the email, accepting the calendar change, signing.

Two things matter. The waiting items must be few, or you are back to doing the work. And the note for the items that went must be short enough to actually read, or you stop reading it and lose the picture. A short brief, one screen long, is the usual answer, and it is the subject of the last chapter.

What it should cost, in effort

Owners ask about price. The more useful number is hours of your attention.

A build done this way costs you the discovery call, one or two short sessions to draw the approval line and check the first drafts, and about ten minutes a day for the first two weeks while it learns your corrections. After that it should cost you the time it takes to read the brief. If it is costing more than that a month in, the process was not ready, and the honest fix is to go back to Chapter II.

Common mistakes

Building the dashboard first. A dashboard is a place to look. You already have too many. Build the work, then decide if anyone needs a view of it.

Copying the data. A second list of customers, a second calendar, a second folder. Within a month they disagree and nobody knows which is true. The system reads from the original.

Automating the whole process at once. Build the step that waits. Watch it for two weeks. Then build the next one. Nine steps at once is nine things to debug at once.

Letting the system talk to customers before it has talked to you. Every outgoing message starts as a draft you approve. The line moves later, once you have seen a hundred drafts you would have sent yourself.

What comes next

Something is now running inside your tools. It handles the work, it asks you when it should, and it leaves a note when it does not need to.

The question is what happens in month three. Chapter IV is about that: why systems drift, what keeps them honest, and why the person who built it should still be around.