Presenting a technical audit to a client who will not read it

Three findings, one number and a date. How to turn forty pages of crawl data into a ten-minute conversation that gets approved.

A thorough technical audit is a hard thing to sell a decision from. It is long, it is specific, and most of it is addressed to a developer rather than the person paying the invoice. Sending the document and asking for approval is the most common way good audit work stalls.

Lead with three findings, not thirty

Pick the three items with the highest impact and present only those. Everything else stays in the document as the record of work. A client who approves three fixes this month will approve three more next month; a client shown thirty approves none.

Convert every finding into a business sentence

"Mobile LCP is 4.8 seconds on the emergency-repair template" is a fact. "The page most of your emergency callers land on takes almost five seconds to appear on a phone" is a decision. Same finding, different audience. Keep the technical phrasing in the appendix for whoever implements it.

Attach a number and a date

Every recommendation should arrive with an effort estimate and a proposed completion date. Not a vague sequence — a date. This is what turns an audit from a document into a plan, and it is the difference between "we will look at it" and a scheduled piece of work.

Never present the file cold

Walk through the three findings live, then send the document as the follow-up. The audit is the evidence behind the conversation; it is not the conversation.