The documentation that lives in Dave's head

I ran a home-technology integration business for years. Here is the sentence that cost us the most money:

“Ask Dave, he installed it.”

Hundreds of systems in the field. The as-builts were done for the big jobs and “coming” for the rest. Every service call started with twenty minutes of archaeology, on the clock, before anyone touched a cable. Which rack. Which switch. Which input the client calls “the Sky one”. All of it in Dave’s head, and Dave was at another job.

This is not an integrator problem. Swap “system” for “site”, “patient” or “matter” and every service business has a Dave. The documentation is the thing everyone agrees should exist and nobody has time to write, because writing it is the one job that is never urgent.

Why it never gets written

Three reasons, and none of them is laziness.

1. It is done last. The documentation is the final step of a job that is already over budget by the time you get there.
2. It is done cold. By the time someone sits down to write it, the job is two weeks old and the details have gone soft.
3. It is done from nothing. A blank template is the most expensive starting point there is.

The fix is to attack all three at once: write it first, write it warm, and never start from blank.

The handover pack that writes itself

By the time a job finishes, almost everything the documentation needs already exists somewhere. The proposal says what was sold. The configurator export or the equipment list says what was installed. The rack photos say where. The job notes say what changed on the day.

A crew can read all of those the day the van leaves and draft the handover pack: system overview, device list with locations, network map, the three things the client is most likely to ring about and what to tell them. In your template, in your words, with a short list at the top of what it could not work out from the sources.

Then the technician reads it, fixes two things, and signs it. That order is the whole trick. The crew writes while the tech drives. The tech signs.

What changes on the next service call

The call comes in. The crew matches the client to the system record, pulls the handover pack and the last three tickets on that room, and puts them in front of whoever picks up. The twenty minutes of archaeology becomes thirty seconds of reading. Often the first reply goes out with the right question already in it: “Is the little green light on the box behind the TV on or off?”

That is where the money is. Service plans are the best revenue in an integration business, and the service calls that eat them are the ones that start with nobody knowing what is there.

What stays with Dave

Dave’s judgement. The crew will not know that the client’s brother-in-law “helped” with the network last Christmas, or that the lounge amplifier runs hot and you should mention it before it fails. Dave adds those lines in the two minutes he spends reading the draft. Which is the point: documentation written by a machine and signed by a person captures Dave’s knowledge instead of replacing it.

Where to start

Not with the backlog. With the next job. One handover pack, drafted by the crew, signed by the tech, measured by how long the next service call on that system takes. If it works, the backlog is just the same job run two hundred times, and the crew does not mind repetition.

If your version of Dave is a real person who is about to retire, this is the single most useful place to put AI in the business, and it is a four to six week build.