Agency Partner Playbook: How To Sell Follow-Up Cleanup Without Promising New Leads

A contractor asks why the agency's leads are not turning into appointments. The campaign report lists form submissions. The office has a callback sheet. Neither document shows who accepted responsibility for the next reply. Adding another report will not settle the question unless someone can connect those records.

This agency partner playbook describes a follow-up cleanup review of one client-authorized question. The agency supplies context; the reviewer examines the agreed records and writes a handoff for the person who can approve a change. The agency does not take over the contractor's calls, and the reviewer does not make the contractor's business decisions.

The method and examples below are illustrative. They are not reports from a client engagement. For an example of the output format, inspect the sample report library before sending any records.

Start with a question the records can answer

"The leads are bad" mixes several questions. A campaign can attract the wrong service requests; a form can lose information; an office can miss an assigned task. A follow-up review should name the handoff it will inspect rather than assume which explanation is correct.

A usable first question is: "For web-form inquiries received during the agreed week, which records show a named owner accepting the next action?" Specify the form, date field, timezone and inclusion rule. A different question about replies would need evidence of the reply itself, not just an assignment.

Choose the period before examining the outcome. Record any exclusions, such as internal tests or confirmed duplicates, and retain the reason for each. If the office handles calls and forms differently, keep them separate until the event definitions match. One caller who also submits a form may be one inquiry with two events, not two opportunities.

A small sample can reveal a problem worth checking. It cannot tell you how often that problem occurs across the whole account unless the sampling method supports that conclusion. Do not select only messy rows and then present their failure rate as campaign performance. The agency client fit scorecard can help structure the initial conversation; its score is not proof that an account will buy or benefit.

Put a person beside each responsibility

Before sharing a packet, agree who will supply the evidence, who will question it and who will make the operational decision. Job titles alone are not enough. "The office" leaves a task unowned when two people assume the other person accepted it.

The person who approves a change may delegate its execution to a named staff member. Keep both names in the decision sheet. An agency contact's willingness to help does not establish permission to export the whole CRM. A reviewer who can see a record does not automatically have permission to contact the person in it.

Prepare a narrow, authorized packet

Write down the purpose, permitted recipients, record types, allowed uses and retention or deletion arrangement before transfer. Use the client's approved sharing method. If any of these decisions remain unclear, start with public pages or a synthetic walkthrough instead of requesting production records.

Start with the fewest redacted rows that can address the agreed question. Keep only the fields the review needs: a local row identifier, source event, timestamp with timezone, assigned role, acceptance evidence, latest supported action and current stop state. Where a field is missing, write "missing" and identify the source that could resolve it.

Remove names, phone numbers, email addresses, property addresses, payment information and unrelated notes. Check screenshot edges, browser tabs, document comments and filenames too. Redaction is a practical reduction step, not a guarantee that the remaining combination of details cannot identify someone. Have the authorized sender inspect the actual file before sharing it.

Do not include passwords, two-factor codes, full customer recordings or unrelated private documents in a first-scan packet. If the question cannot be answered without sensitive information, hold that part of the review and agree a suitable process with the responsible owner. Do not quietly broaden access because a spreadsheet is inconvenient.

When the reviewer receives the packet, acknowledge its version and declared scope. If it contains more data than agreed, follow the client's approved handling procedure rather than forwarding it to another person for convenience. Record the issue without reproducing the private content in the project log. The first-scan readiness guide describes the site's intake boundaries.

Separate a supported gap from an unanswered question

The following fictional example concerns an agency and a home-service contractor reviewing form ownership. The row IDs, events and decisions are invented to demonstrate the method. They are not customer records, measured results or a testimonial.

The agency should not call F02 a lost sale. The records show a disagreement about ownership. There may have been an action outside the exported system, or the sources may use different definitions. Write the uncertainty plainly: "The included records do not establish who accepted this task."

Likewise, the supported assignment in F01 proves only the assignment. A generated draft is not a sent reply; a sent reply is not proof of delivery; a delivery record is not an appointment. Keeping these events separate prevents a tidy report from overstating what happened.

Useful labels are supported, missing, contradictory and out of scope. Attach the source, its date and the relevant limitation to every finding. If two records use different timezones, resolve that difference before reporting a delay. Keep the original value alongside any documented normalization so another reviewer can follow the calculation.

Describe the deliverable before discussing a larger engagement

A proposal should tell the client what they will receive even if the sample reveals no actionable defect. That might be a reviewed evidence table, unresolved questions, one prioritized option and a decision sheet. A finding of "no supported change from this packet" can be a legitimate result. Inventing a problem to justify the service is not.

Specify the review boundary: included channels and period, required inputs, review output, revision allowance if offered, and what happens when information is incomplete. State whether implementation is excluded. Do not imply that a diagnostic fee includes a new CRM, customer calling, campaign management or continuing support.

Use the actual agreed fee and deliverables in a client proposal. This playbook does not establish a price, referral commission, reseller agreement or service-level guarantee. Those terms need separate agreement by the appropriate people. The current agency partner page and service terms are starting points for checking fit, not permission to invent a partnership arrangement.

The wording should match the service actually being offered. The FTC's advertising guidance calls for truthful, non-deceptive claims backed by evidence. A disclaimer cannot make an unsupported headline reliable. Treat this as a content boundary, not legal advice about a particular contract.

Require a decision record before a live change

Mark the packet ready for owner review, held for a specific missing item, or out of scope. "Ready" means the owner can assess the proposed action; it does not mean the action is approved or already completed. An unresolved row need not stop unrelated, clearly authorized review work.

For each proposed change, write the observed problem, source references, exact change, approver, operator and planned verification. Include a rollback step when the change is reversible. For example, a task-routing adjustment should name the old destination, the proposed destination and the test that would show the new route works.

Agree on a controlled test with synthetic data where possible. Confirm the intended owner receives and accepts the test task, and check that the change does not create a duplicate message. Do not send test messages to real customers merely to obtain a screenshot. If the test fails, preserve the result and follow the approved rollback plan.

The completion receipt should distinguish proposed, approved, applied and verified. Record the actual test result and any remaining limits. A corrected assignment rule supports a claim about that rule, not a claim that the agency recovered a sale or improved retention.

Make a repeat review conditional on a useful question

At the closeout meeting, ask the owner to point to a finding and explain what they decided. Record the question still open. If nobody can use the output, narrow the review question or stop that service before proposing another review.

A weekly or monthly review may be appropriate when the client has a continuing reason to inspect the same handoff and agrees to the work. Keep definitions, inclusion rules and evidence requirements stable so periods can be compared. Record changes in the sample or workflow. A smaller queue after a configuration change does not by itself prove causation, and a few reviewed rows do not establish an account-wide trend.

For public case material, obtain the appropriate permission and verify each claim separately. A fictional sample should remain labeled fictional. Do not turn an agency's interest, an accepted proposal or an internal test into a testimonial or a customer outcome.

The NIST Privacy Framework is a voluntary resource for identifying and managing privacy risk; it is not a certification of this workflow. For an agency's public explanation, Google's people-first content guidance is relevant to usefulness and reliability. Neither source validates the sample, promises search visibility or proves a commercial result. These references were checked October 5, 2026.

Frequently asked questions