How to Get a Decision in Writing Without Slowing the Job

Why this matters

Every shop that has been burned by an unpapered approval reaches the same conclusion and then quietly stops doing it, because getting a decision in writing appears to cost the tech twenty minutes standing in a mechanical room waiting for a phone to ring. The cost is real, but it is not caused by writing. It is caused by composing the decision at the moment somebody needs it. A request that is written from scratch on site, sent as an open question, and answered by a customer who now has to invent options, is slow. A request that already exists as a bounded artifact and needs four blanks filled is faster than the phone call it replaces, and it leaves a record the phone call never had.

Step 1: Break the delay into the four parts, because you only control three

Total time from finding something to having an answer is compose plus deliver plus decide plus return.

• Compose is you writing the request. Fully yours. This is where the twenty minutes actually goes.
• Deliver is the message reaching a human. Mostly yours: the channel you picked and whether you have the right person's number.
• Decide is the customer thinking. Not yours, but the shape of your request sets how much thinking there is to do.
• Return is their answer reaching you and you seeing it. Yours, and it is where a request sent to an office email at 7 p.m. dies overnight.

Shops trying to speed this up almost always attack decide time by pushing the customer, which is the one part they do not control and the one that resents being pushed. Attack compose and shape instead.

Step 2: Build the request as a fixed artifact with seven fields

Write this once, save it where a tech can pull it in one tap, and never compose one from nothing again. Seven fields, and each one is doing a specific job:

1. What I found. One sentence, observation only, no conclusion. "The isolation valve at the tie-in is seized and weeping at the stem."
2. What happens if it stays as is. The consequence with a time frame attached. Without a time frame the customer reads it as optional forever.
3. Option 1, with the added hours and today's new finish time. Not just the hours. The finish time is what the customer is actually deciding about.
4. Option 2, with what it leaves in place and what a return visit costs in hours. The do-nothing path is a real option and it needs its price stated, or the request reads as a sales pitch with one exit.
5. What is unaffected either way. One line. Without it, customers assume the whole job is now on hold, and that assumption generates the phone call you were trying to avoid.
6. When you need the answer, as a clock time. "I can hold the site until 2:15." A real deadline with a real reason behind it, never an artificial one.
7. How to reply. "Reply 1 or 2." One word answers arrive faster than sentences, and they are unambiguous a year later.

The fields the tech fills on site are one, three, four, and six. Two, five, and seven are written once per job type and reused. That is the whole trick: three of seven fields are already done before the truck rolls.

Step 3: Cap it at two options

Two options, three at the outside when a genuinely different third path exists, such as deferring to a scheduled return. Beyond three, decide time grows faster than the value of the extra choice, because the customer stops choosing and starts asking questions, and every question is another round trip.

An open-ended request ("let me know how you want to handle this") hands the customer the composition work you just avoided doing yourself. They are less equipped to do it than you are, so they do it slowly, or they call, which converts your written record back into a verbal one.

Step 4: Send it to the person who can answer, on the channel they answer on

The fastest artifact in the world is slow if it lands in an inbox nobody watches. Record the approving person's preferred channel on the account the first time you find out, and use that channel every time. Text for most residential and small commercial. Email where a purchase order number has to be issued, because the number has to be typed by somebody in an office anyway.

For managed property and commercial accounts, whether the recipient can commit the payer is a separate question and it is the one that voids the most invoices; the sibling article on verbal approval covers how to establish that before you need it.

Step 5: Log the answer as it arrives, not at end of day

The reply is the record. It needs to attach to the job, not sit in a tech's personal message thread where nobody can find it when an invoice is questioned nine months later. If your system lets a tech attach the thread or a screenshot to the job as they go, that is thirty seconds; end-of-day reconstruction is ten minutes and it will not survive a busy week.

The same decision, run both ways, timed

A tech is 3.0 hours into a quoted 6.0-hour visit and finds the isolation valve seized. Correcting it adds 1.5 labor hours, so the finish time moves from about 3:00 to about 4:30. Not correcting it means the new equipment goes in behind a valve that cannot be closed, so the next service on that line requires isolating upstream, which is a return visit of roughly 1.0 hour on top of whatever the actual work is.

Path A, composed on the spot. The tech calls. No answer. He leaves a voicemail that tries to explain the valve, the options, and the timing in one breath. The customer calls back 26 minutes later, having understood about half of it, and they talk for 6 minutes. The tech resumes at minute 32. The office writes up the approval the next morning, about 19 hours after the finding, from the tech's recollection.

Path B, the artifact. The tech opens the saved request, fills four fields, attaches a photo of the weeping stem, and sends it. That takes 2 minutes. The customer reads a request with two options and one clock time and replies "1" nine minutes later. The tech resumes at minute 11, and the written record exists at minute 11 rather than at hour 19.

Idle time: 32 minutes against 11, so 21 minutes saved on this one event, and a record that is contemporaneous instead of reconstructed.

Scale it honestly. A shop with 6 techs averaging 3 approval events per tech per week has 18 events a week. At 21 minutes each that is 378 minutes, or 6.3 hours of idle time a week across the crew, about 1.05 hours per tech. Against roughly 30 on-site hours per tech per week that is about 3.5%. Be precise about what that 3.5% is: it is idle on-site time recovered, not sold time. It only becomes sold work if the schedule has demand waiting to absorb the freed capacity. If it does not, what you have bought is a crew that finishes closer to on time and a record that exists before the dispute rather than after it, which is worth having on its own.

The failure mode of Path A is not the 21 minutes. It is hour 19. An approval written up the next morning from memory is exactly the document that gets challenged, because the only person who can attest to it is the person who benefits from it.

Where this changes shape

Two conditions genuinely invert the method rather than just adjusting it.

Multiple approvers with a purchase order requirement. Here the two-option text is the wrong artifact, because the person you are texting cannot commit anyone. The pre-built artifact becomes a request for a purchase order number that contains the scope and hours in a form the office can paste into their system, and the on-site contact's role is to route it, not to answer it. Compose time is still the thing you pre-build; the recipient and the ask change.

A life-safety finding. This is not a decision request at all and the artifact does not apply. Nobody is choosing between two options. Note specifically that step one's photograph is forbidden in some of these cases: in a space with a gas odor, everyone leaves immediately, no switches or lights are touched, and no phone is used inside, which means no photo is taken until you are outside and the call to the utility has been made from there. Where energized equipment is involved, keep people clear and de-energize at the disconnect and prove dead with a tester checked on a known live source before and after the reading, per NFPA 70E-2021 section 120.5 and 29 CFR 1910.333(b)(2). The written record of a dangerous condition still goes to the customer the same day, plainly, but it is a notice, not a menu.

How to tell it is working

• Time three events with a stopwatch, from finding to answer received. If any of them exceed about 15 minutes of idle, look at which of the four parts consumed it, because the fix differs completely: compose time means the artifact is not saved where the tech can reach it, deliver time means the wrong contact, return time means the wrong channel.
• Open a job from six months ago and find the approval. If it takes more than a minute, the answer is being logged somewhere that will not be found under pressure.
• Count the requests that got a question back instead of an answer. More than one in five means the artifact is not bounded: usually the missing field is the do-nothing option or the "what is unaffected" line.
• Check whether techs are still calling first and writing after. That habit reappears quietly under schedule pressure, and it is the single tell that the artifact is not actually faster on your jobs.

References

• NFPA 70E-2021, section 120.5, for the live-dead-live proving sequence, which binds through your employer's electrical safety program and through 29 CFR 1910.333(b)(2)
• See related: Why Verbal Approval Is Worth Less Than It Feels, How to Get Approval Before You Do Extra Work, The CYA Email After a Verbal Agreement