Explaining findings to a small business

An audit the owner can't understand is an audit that doesn't get acted on, and the fault is yours, not theirs. The craft of this lesson is translation: every technical finding you present gets exactly two sentences. A plain sentence that says what is true without a single term of jargon, and a money sentence that says what it costs while it stays unfixed. If you can't write both, you don't understand the finding well enough to charge for it yet.

Who you're talking to

The owner of a twelve-person company is smart. She runs payroll, negotiates leases, reads contracts, and made it through last year's insurance renewal. She is not technical, and she should not have to be, any more than you should have to read her balance sheet to buy her product.

So a summary full of p=none and permerror is not a display of expertise. It is a failed translation, and the failure belongs to the practitioner. Jargon in the appendix is documentation; jargon in the summary is you making your problem her problem.

Of everything the free health check flags, missing DMARC is among the most common findings and, from what I can see, among the least acted on. I think the reason is translation. "No DMARC policy published" costs nothing in an owner's mental model. "Anyone on the internet can send email pretending to be you" costs sleep. Same fact, different language, different outcome.

The two-sentence pattern

The audit workflow produced a findings list. Here is the translation table for six findings you will actually present, each shown three ways: the technical finding as your notes record it, then the plain sentence, then the money sentence.

Missing DMARC

Technical: no TXT record at _dmarc. on the domain; no policy, no reporting address.

Plain: "Right now, anyone can send email that claims to come from your company, and you'd never know it happened."

Money: "If a scammer invoices your customers under your name, you pay in cleanup and lost trust; and the big mailbox providers now expect this record from senders, so it also puts your own mail on thinner ice every year."

A dead SPF include

Technical: the SPF record still includes a service the client cancelled; if that service retires its record, evaluation returns permerror.

Plain: "Your domain's public list of approved senders still names a tool you stopped paying for."

Money: "The day that entry goes stale, receivers can no longer confirm your mail is really yours, and campaigns start landing in spam with no warning; the fix costs ten minutes now or a bad week later."

Complaint creep

Technical: Postmaster Tools spam rate trending upward toward the 0.3% ceiling over three months.

Plain: "A growing share of your recipients are pressing the spam button on your mail."

Money: "Google publishes a hard ceiling; cross it and mail to your biggest audience starts foldering wholesale, so every campaign after that earns a fraction of what it used to."

A domain gone cold

Technical: no meaningful sending volume for eight months; the relaunch list is the full historical file.

Plain: "Your domain hasn't sent in so long that the filters have forgotten who you are, and to them a forgotten sender looks like a stranger."

Money: "If the relaunch blasts the whole old list on day one, the announcement your team spent a quarter on goes to spam, and the damage follows the domain into the next send too."

Quarantined B2B mail

Technical: mail to one corporate customer accepted, then held in the tenant's quarantine; notifications off; retention default 15 days, then deletion.

Plain: "Your invoices to that customer are sitting in a security holding pen their staff never sees, and after two weeks each one is deleted."

Money: "That's cash aging in someone else's quarantine; every unfixed week is unpaid invoices and a deal team wondering why the client went quiet."

A listed shared IP

Technical: the ESP's shared sending IP appears on a major blocklist; the listing is another tenant's behavior, not the client's.

Plain: "The address your email company sends your mail from got blacklisted because of someone else on the same address."

Money: "Some receivers refuse everything from that address, so a slice of what you send simply bounces until your provider fixes it or moves you; until then you're paying to send mail that can't arrive."

Notice what the money sentences never do: quote an invented percentage. "Every campaign earns less" is true and honest. "You're losing 34% of revenue" is a number you made up, and one sharp question destroys the whole engagement.

Not everything is a fire

The two-sentence pattern makes findings vivid, which creates a temptation: make them all vivid. Resist it. Missing DMARC on a company sending forty invoices a day is real and worth fixing this week; it is not an emergency, and calling it one is a small lie. A practitioner who marks everything critical trains the client to ignore severity entirely, and then the day something genuinely is on fire, the alarm sounds exactly like the last five false ones.

Rank findings by cost, say plainly which ones can wait, and you become the rare vendor whose "urgent" means urgent.

The conversation, done wrong and done right

No client stories here; this is the shape the conversation takes, and it usually goes like this.

Wrong: "So, your SPF has a dead include that could throw a permerror, and DMARC is at p=none with no rua address, which means you've got zero visibility into alignment failures." The owner nods, absorbs nothing, and asks the only question available to her: "how much?" Since nothing you said sounded expensive, every price you quote now sounds high.

Right: "Two things. First, your mail could start failing an identity check any day, because your settings still point at a tool you cancelled; when it fails, invoices land in spam. Ten-minute fix, I'd do it today. Second, nothing currently stops a stranger from sending email as your company. Less urgent, but cheap to close this week." The owner asks which customers are affected and what the two fixes cost together. She is now buying outcomes, not tolerating jargon.

Same findings. The second version required no simplification of the facts, only translation of them.

What you hand over

One page. Findings ranked by cost, highest first, each carrying its plain sentence and its money sentence. Below them, the fix plan: what happens in what order, with dates. That's the whole page.

The records, lookups, screenshots and evidence go in a separate technical appendix. It exists so her IT contact, or the next practitioner, can verify every claim you made; it is not the deliverable, it is the deliverable's receipts. If the appendix leaks onto page one, you've shipped your notes instead of your judgment.

One more thing belongs on that page, and it's a promise you can keep: verification. You will confirm each fix is live and correct, from public DNS, on a stated date. What you will not promise is an inbox rate, because nobody outside the mailbox providers can measure one; the full argument, and the sentences that protect your reputation when a prospect pushes for a guarantee anyway, is its own lesson.

And the report should say, in writing, that these settings break silently over time, because they do; the next tool the client connects can undo a fix without anyone noticing. That sentence is honest, and it is also the beginning of the monitoring conversation.

Next, packaging: turning audits, fixes and monitoring into services with honest scopes and prices.

Terms from this lesson

• plain sentence - the statement of what is true, written so a non-technical owner understands it on first read, with zero jargon.
• money sentence - the statement of what a finding costs while it stays unfixed, without invented numbers.
• technical appendix - the records, lookups and evidence behind the findings, kept separate from the one-page summary so it can be verified without being read first.

Check yourself

1. Your notes say: "SPF contains an include for a decommissioned service, producing a permerror on evaluation." Which summary line goes in front of the owner?

"Your SPF evaluation returns permerror due to a stale include mechanism.""Your domain's list of approved senders still names a tool you cancelled, and the error it causes can quietly send your mail to spam.""Your domain has been compromised by a third party and needs an urgent security response.""There's a minor cosmetic DNS issue; no action needed."

2. Why shouldn't every finding in the report be marked critical?

Clients only ever pay for one critical item at a timeBecause severity inflation trains the client to ignore you, so a real emergency later sounds like every false alarm before itBecause most findings fix themselves if you wait

3. At presentation time, what can you honestly promise?

A specific inbox placement rate once the fixes are liveThat each fix will be verified as live and correct, from public DNS, by a stated dateThat the client will never have a deliverability problem again

Scenario

You've presented the one-page report. The fixes are done and verified, and the owner is pleased. Then she asks the natural question: "So we're fixed forever now, right?"

What do you say?

"Yes, you're all set.""No, email breaks constantly. Honestly, you'll probably need me back within the month.""Everything we found is fixed and verified as of today. The honest caveat: these settings change whenever your tools change, and they break without symptoms. I'll leave you the short list of what to watch, or I can watch it for you.""That's covered in the technical appendix."