A client report template that survives questions

What the report has to do, and what it must never promise

Deliverability work is bought on trust, reported in numbers and judged months later. A report that claims causation is a liability the day a campaign underperforms. A report that only shows a chart going up is worse, because it invites the client to draw the causation themselves.

The distinction to hold in every paragraph: you report what you did and what was observed. The link between the two is a hypothesis, and it is labelled as such.

The change log is the report

Write the change log as the work happens, not at the end of the month. Every line is one change, one date, one owner, one expected effect and one way to reverse it. Without it, a reading three weeks later has no explanation available, and the temptation is to credit the tool that happens to be on the invoice.

The log below is fictional and written for this guide. Dates are relative on purpose.

A change log that contains client side changes is not a failure of process, it is the process working. The report's job is to make those lines visible, because they are exactly what a later reading will depend on.

The template, section by section

Seven sections, in this order. Keep the order stable across periods and across clients, so a client can compare two reports without relearning the document.

1. Scope. Domains, subdomains and mailboxes covered, with the count. Anything outside the scope is named, so nobody assumes it was watched.
2. Change log. The table above, agency lines and client lines together.
3. Authentication status. SPF, DKIM and DMARC, per sending domain, as observed at the start and at the end of the period. This is a configuration fact, not a prediction, and it is the most useful line in the report.
4. Placement observations. One table per run: instrument, seed count per provider group, folder split, missing seeds counted separately. Always with the unit written out: seed addresses, not recipients.
5. Client side signals. Hard bounces, complaints where the provider reports them, unsubscribes, taken from the client's sending platform. These are the only figures in the report about real people.
6. Open questions. What the period could not settle and why, in plain sentences. A report with an empty open questions section is a report that overclaims.
7. Spend. Per mailbox subscriptions, test credits consumed, and the total for the period, matched to invoices.

One page per section at most. A deliverability report that runs to thirty slides gets skimmed, and the open questions section is the first casualty.

The observation table, written so it cannot be misread

Most disputes come from a single ambiguity: the reader assumes a placement figure describes their customers. Kill the ambiguity in the caption, in the column header and in the footnote. The table below is fictional.

The last sentence of that footnote is the one that saves the agency. A single headline percentage invites a comparison with last month that the sample cannot support, and it travels through the client's organisation without its caveats.

The access ledger, and the revocation you owe the client

Running warmup and testing across client accounts means holding access to other people's mail. Keep a ledger, one row per grant, and treat offboarding as a deliverable rather than an afterthought.

The revocation paths worth knowing on Google accounts, as the provider documents them:

• Application specific passwords require 2-Step Verification on the account, cannot be created for accounts using only security keys or under Advanced Protection, and are withdrawn with Remove in the App Passwords list. Google states that after revocation "the app can't access your Google Account again". Source: Google Account Help, app passwords.
• Authorised third party apps are listed in the Google Account and can be reviewed or removed at any time, with one limit Google spells out: "you may need to contact the developer of the app to request that they delete the data they already have". Source: Google Account Help, third party access.
• Microsoft and other providers expose equivalent screens, but the path depends on the tenant and on admin policy. Open and test the path in the client's own tenant, then write it in the ledger. We have not verified every tenant configuration, and an untested revocation step is not a revocation step.

Revocation stops access. It does not delete what the vendor already stored, including warmup message content and metadata. If the client needs deletion, request the vendor's procedure in writing at onboarding, keep the reply, and quote it in the offboarding section rather than paraphrasing it.

Offboarding checklist, run in this order: disconnect the mailbox inside the tool, revoke the grant at the provider, confirm the grant is gone by reloading the provider's list, export the data, cancel the per mailbox subscription, then write the removal date in the ledger and in the final report.

Exports, and what the client actually owns

Everything in the report must be reproducible from files the client keeps after the engagement ends. Export at every period close, not only at the end.

1. Raw placement rows, per provider group and per mailbox, with seed counts. Summary charts are not an export.
2. Authentication records as observed, so a later dispute about what was configured has evidence.
3. Warmup activity, volumes per day and per mailbox, the only trace of what was actually done to the mailboxes.
4. Bounce, complaint and unsubscribe logs from the client's sending platform. These belong to the client already, and should never live only in the agency's account.
5. The change log itself, as a file, not as a paragraph inside a slide.
6. Invoices, per mailbox and per credit pack, matched to the spend section.

Two practical points. Accounts and credits are usually tied to the party that opened them, so decide at onboarding whether tools are bought in the client's name or the agency's, and write the answer in the ledger: it decides who keeps the history at the end. And check the export format in the first week of any tool, because a product that only draws dashboards will leave you rebuilding a year of history by hand. Which export formats each product offers is not something we have tested, so verify it in your own account rather than trusting a feature list.

Costing the period without surprises

The spend section fails in one predictable way: a per mailbox price is quoted for one mailbox, then the invoice arrives for the whole fleet. Warmup is sold per mailbox at MailReach and at Warmup Inbox, placement testing is sold in credits at GlockApps, list verification is sold per address at ZeroBounce, and Instantly folds warmup into its sending plans instead of billing it separately. Four different units, so a single number for the period means nothing without them.

Entry level per mailbox pricing sits at $19.50 per month for the MailReach all-in-one plan and $15 per month for the Warmup Inbox entry plan, before any multiplication by mailbox count, by month and by client. Price the fleet in the cost calculator, put the result in the spend section, and keep test credits on their own line: they are consumed per run, so a month with a re-test costs more than a quiet one.

The sentences that get agencies into trouble

Every sentence in the right column is either a causal claim without a control, a rate for recipients drawn from seed addresses, or a promise about a filter you do not operate. The left column says less and holds up a year later, which is the only test that matters for a document a client keeps.