# Follow-Up Sequence Planner — Field and Testing Guide - **Version:** 1.0 - **Updated:** July 24, 2026 - **License:** Personal use - **Included file:** `follow-up-sequence-planner.csv` The planner is a plain CSV for defining a small follow-up sequence before anyone configures a messaging tool. It helps make the trigger, audience, purpose, timing, owner, human review, and stop condition visible on the same row. The included rows are a **FICTIONAL EXAMPLE**. They use the reserved `.invalid` domain and are not MethodCo customers, a working campaign, evidence of performance, or permission to contact anyone. Delete or replace every example before using the file. ## Start with a real and permitted event A sequence needs a legitimate trigger. “We have an address” is not enough. Write the event that makes the message relevant, such as a person submitting a specific inquiry and asking for a response. Before planning a message, confirm: - The recipient knows why the organization has their details. - The intended reply matches what the person requested. - Any consent or permission required for the channel is present. - The sender can honor the timing and promise in the message. - Withdrawal, reply, failure, and closing signals can stop later steps. This guide cannot decide the legal basis, consent rule, or professional requirement for a real use case. Get qualified advice when the situation requires it. ## Field guide ### Step ID Give each row a stable, human-readable identifier. Keep it stable across reviews so that a correction can name the affected step. ### Trigger State the observable event that makes the step relevant. Avoid vague triggers such as “lead entered funnel.” Name the real event and any validation required. ### Audience Describe the person who should receive or be affected by the step. Do not treat an entire database as one audience. The audience must remain consistent with the original context and permission. ### Purpose Write one useful reason for the step. An acknowledgement, scope question, promised update, or closing notice has a distinct purpose. If the row has several goals, split it or simplify it. ### Timing State when the step is considered, using time a person can verify. Timing is not authorization to send. The trigger, permission, context, and stop conditions still need to be true. ### Owner Name the role or person accountable for the step. The owner is responsible for the decision and the result even if a tool prepares or routes part of the work. ### Human Review Describe what a person must inspect or approve. Review may include the requester’s actual question, promised response window, sensitive context, exceptions, or the final message. “Human checks it” is too vague. ### Stop Condition List the events that make the step inappropriate. Common examples include a reply, withdrawal, decline, completed request, invalid address, delivery failure, changed scope, or a person deciding to close the sequence. ### Status Use a small controlled set during planning, such as Draft, Ready for test, Paused, or Retired. The supplied rows use FICTIONAL EXAMPLE so they cannot be mistaken for live work. ### Notes Record a necessary exception, dependency, or test result. Do not store unnecessary sensitive detail. The operational record should point to protected source information rather than copying it. ## Replace the examples safely 1. Save an untouched copy of the downloaded version. 2. Duplicate the file into a working copy. 3. Delete every fictional row. 4. Add one row for the first legitimate event. 5. Name its audience, purpose, owner, review, and stop condition. 6. Add later steps only when the previous decision is clear. 7. Review the sequence with the person accountable for the customer promise. Do not import the example rows into a live messaging platform. ## Manual test before any live use Test the plan with controlled records that do not contain real customer data. - Expected path: a valid request reaches the correct owner. - Reply path: later steps stop after a reply. - Withdrawal path: all later contact stops. - Failure path: an invalid destination creates a visible error. - Duplicate path: one request does not create duplicate messages. - Delay path: the owner can see and correct a missed timing promise. - Manual path: the process still works when assistance is unavailable. For each test record: - Input and expected result: - Actual result: - Evidence inspected: - Person who reviewed it: - Correction required: - Retest result: Do not mark the sequence ready because a single expected-path message appeared. Exceptions and stopping behavior are part of the work. ## Message review Before approving any message, ask: - Does it identify why the person is receiving it? - Is the promise specific and achievable? - Does it avoid false urgency, pressure, and unsupported claims? - Is the next action clear? - Is there a simple way to reply, withdraw, or ask for help? - Does the sender identity match the real accountable organization? - Has a person reviewed the final text in its real context? An acknowledgement should not pretend a substantive review has occurred. A reminder should not imply personal attention when nobody reviewed the underlying request. ## Ownership and maintenance Choose one person to review the live sequence after material changes and at a reasonable fixed interval. Record the current version, active rows, last test date, and next review date. Retire obsolete steps instead of leaving them silently active. If a tool is later configured, keep the CSV as a readable description of the intended behavior and update it when the behavior changes. The tool configuration is not the only documentation. ## Privacy, permission, and security Store the minimum data needed for a legitimate purpose. Limit access, protect exports, remove obsolete copies, and follow the requirements that apply to the real channel, audience, jurisdiction, and profession. Never use inquiry data to create unsolicited outreach merely because the file can hold it. Do not put credentials, secret keys, payment data, health details, government identifiers, or other sensitive records in this planner. ## Limitations This CSV and guide are planning documents. They do not send messages, capture consent, validate an address, connect to a form, create a customer record, monitor failures, or prove that a communication is lawful, fair, secure, accessible, or effective. They are not legal, privacy, security, marketing, or compliance advice and do not guarantee a response or sale. The examples are fictional demonstrations. They are not a recommended cadence for every situation. A person remains responsible for permission, audience, claims, timing, access, promises, human review, exceptions, and every decision to continue or stop. ## Version and updates Version 1.0 is the first published edition. Material changes to fields, status logic, or instructions receive a new visible version and dated history entry. Existing downloads remain fixed; check MethodCo.org for the current named version. Personal-use license: you may adapt the files for your own work. Do not resell, redistribute, or present them as professional certification, legal approval, or MethodCo validation of a live sequence.