How to Route Wrong-Contact, Referral, and Forwarded Replies
A wrong-contact reply can improve account data, a referral can reveal a possible route, and a forward can show internal circulation. None proves that the next person is interested or can be contacted automatically. This playbook preserves the original person's treatment while verifying the new route.
DEFINITION
What is this about?
Route wrong-contact, referral, and forwarded replies by separating the original person's status from the account's status. Apply any unsubscribe or stop instruction first, classify why the person is wrong, verify a named or role-based referral independently, and preserve a forward as an unconfirmed route until the recipient responds. Replace contacts only under a defined rule; never transfer interest, consent, qualification, or authority from one person to another.
KEY TAKEAWAYS
- Wrong person does not automatically mean wrong account, and wrong account does not automatically mean permission to search for another person.
- A referral is evidence of a suggested route, not transferred interest, consent, authority, or qualification.
- A forward without a receiving-person response leaves recipient identity and intent Unknown.
- Departure and retirement require employment correction and must not recycle the person into later outreach rounds.
- Person unsubscribe and company stop have different scopes and both take precedence over replacement.
Who this playbook is for
This playbook is for B2B teams that need to continue account research after a recipient corrects the route. It covers direct outreach, account-based follow-up, and industrial buying groups where responsibilities differ across plant, corporate, contractor, distributor, and project organizations.
Contents
1 Separate person status from account status 2 Classify the redirect before finding a replacement 3 Apply the SellersGPT REFER Route Card 4 Verify the new route and preserve stop scope 5 Coordinate replacement without account bombing 6 Illustrative example 7 Common mistakes 8 What this does not mean 9 Common questions 10 Sources and methodology
1. Separate person status from account status
“Wrong contact” is incomplete. It can mean:
• wrong function for this decision;
• right function but wrong site, business unit, or geography;
• no longer responsible;
• departed or retired;
• external consultant rather than employee;
• distributor or contractor route required;
• account no longer fits;
• the person does not want contact;
• the company instructs all contact to stop. Each meaning changes different records. A person can be wrong while the company still fits. A company can fit while the proposed direct relationship is wrong because purchases go through a distributor. A person can be correct but uninterested. Do not translate all cases into one “find another contact” action. Email headers and thread fields can help link a reply to the original message, but they do not verify a newly named person's role. IETF - RFC 5322, Internet Message Format Preserve the exact reply, sender, time, thread, and any named address. Treat the new identity as Claimed until corroborated.
2. Classify the redirect before finding a replacement
Redirect class Evidence Person effect Account effect Replacement default Wrong function “I handle finance, not maintenance” Role mismatch for episode None established Verify relevant function Wrong site/unit Names another facility or division Scope correction Update site relationship Verify site-specific route Departed Reliable notice person left Employment ended None established Mark departed; never recycle Retired Reliable notice retirement Employment ended None established Mark retired; never recycle Named referral Names person and possible function Original remains as stated Possible new route Verify person, role, and treatment Role referral “Ask plant reliability” Original remains as stated Functional clue Research team; do not invent person Forwarded “I forwarded this” Original action recorded Internal circulation possible Wait or verify; recipient Unknown Person stop “Remove me” Suppress person Account not necessarily stopped No replacement until policy permits and scope checked Company stop “Do not contact anyone here” from credible source Suppress source and company scope Stop account outreach No replacement Account mismatch Credible evidence company/application is out of scope Correct person status separately ICP fail or alternate segment No prospect replacement Apply compound classes. “I retired; contact Ana, and remove this address” means retirement, named referral, and person stop. None cancels the others.
3. Apply the SellersGPT REFER Route Card
The REFER Route Card is an original SellersGPT editorial tool.
• R - Reply and scope: preserve literal words and whether they concern person, episode, site, account, or company.
• E - Employment and identity: verify whether the original person remains current and whether a named referral exists.
• F - Functional relevance: define what decision function the new person or team may perform.
• E - Eligibility and treatment: check suppression, company stop, applicable communication rules, existing relationship, and owner.
• R - Route and review: choose update, verify, pause, replace, reroute, or stop; assign an owner and date. Required fields: Field Example state Original person Current / Wrong function / Departed / Retired / Unknown Original treatment Continue / Pause / Suppress / Stop / Review Account and episode Pass / Fail / Unknown / Conflicted Referral type Named / Role / Site / Channel / Forward only / None Field Example state Referred identity Verified / Supported / Claimed / Unknown / Conflicted Functional hypothesis Defined role in this decision, with evidence New-contact treatment Permitted / Restricted / Stop / Review Contact owner One named owner Next action Verify / Contact / Wait / Reroute / Close Review date Dated NIST's Digital Identity Guidelines distinguish identity proofing and authentication at defined assurance levels. NIST - Digital Identity Guidelines A referral is not formal identity proof. The bounded lesson is to keep claimed identity separate from stronger verification.
4. Verify the new route and preserve stop scope
For a named referral, verify:
• the person exists and is currently linked to the organization;
• the source of the name and address;
• the likely functional role in the defined decision;
• site, business unit, and geography;
• whether the person is already a customer contact, active lead, suppressed contact, or duplicate;
• whether outreach through the proposed channel is permitted;
• which owner controls the first action. For a role referral, research the function before the person. “Facilities” could mean local maintenance, corporate real estate, an external contractor, or a shared service. Avoid selecting the most senior title as a shortcut. For a forward, record exactly what is known: the original recipient reports forwarding. Unless the receiving person replies or reliable message evidence identifies them, recipient identity, reading, interest, and role remain Unknown. Do not send a follow-up saying “Your colleague forwarded this to you” when that has not been confirmed. The FTC's U.S. CAN-SPAM guidance and the CRTC's Canadian CASL guidance provide distinct commercial-message requirements. FTC - CAN-SPAM Act: A Compliance Guide for Business CRTC - Canada's anti-spam legislation FAQ A referral does not automatically transfer consent or remove obligations. Obtain jurisdiction- and context-specific review where necessary.
5. Coordinate replacement without account bombing
Within SellersGPT, replacement can be triggered by Wrong Contact, invalid contact, hard bounce, an authorized tenant or system skip, follow-up discovery of mismatch, departure, retirement, or timeout under the active rule. Departure and retirement records must never re-enter a new round as current contacts. Company stop blocks replacement outreach. Replacement should be controlled: 1 close or update the original contact state; 2 preserve person-level suppression independently; 3 confirm the account and episode remain eligible; 4 define the missing functional role; 5 verify one replacement candidate at a time or within the configured pool limit; 6 coordinate with existing contact owners; 7 use a differentiated, role-relevant reason for any permitted message; 8 apply sequence frequency, suppression, and stop rules; 9 record the outcome and do not exceed the configured company contact limit. NIST's Information Quality Standards emphasize objectivity, integrity, utility, and correction for NIST information. NIST - Information Quality Standards SellersGPT uses those as bounded editorial principles: preserve the referral source, mark inference, show uncertainty, and correct stale employment data.
6. Illustrative example
Illustrative example. The company, people, messages, and calculations below are fictional. They are not a SellersGPT customer result or forecast. A fictional exporter contacts Sam Lee, listed publicly as Maintenance Manager at Cedar Foods. Sam replies: “I retired in June. Priya Nair now handles line reliability. Please remove this address.” The team creates three separate facts: Fact State Action Sam employment Retired, source dated today Mark retired; never re-enter a round Sam treatment Person stop Suppress address immediately Priya referral Claimed name and function Verify current employment, role, address source, and treatment Public first-party evidence confirms Priya works at Cedar Foods in reliability, but the specific plant is Unknown. The account still passes its active ICP. The route card is therefore: Original person Retired; Original treatment Suppress; Account Pass; Referral Named; Referred identity Supported; Site scope Unknown; Next action Research site before contact. The record has 6 required referral checks: identity, employment, function, site, duplicate/suppression, and permitted route. Five pass and site remains Unknown, so completeness is 5 / 6 = 83.3%. That calculation does not authorize contact or estimate purchase. The site requirement is a hard gate, so the team researches it rather than averaging the Unknown away.
7. Common mistakes
Treating a referral as endorsement The sender may simply want to redirect the message. Preserve the suggested route, not invented interest. Contacting everyone named in a reply Names can be background context, not invitations. Verify functional relevance and treatment. Reusing departed or retired contacts later Mark employment end state and block future-round selection. Ignoring compound stop language “Ask Alex, but remove me” requires both referral handling and suppression. Assuming a forward reached a specific person Without receiving-person evidence, identity and intent remain Unknown. Replacing a person after company stop Company-level stop prevents contact substitution. Do not interpret it as a list-quality problem.
8. What this does not mean
• It does not require contacting every referral.
• It does not transfer consent, interest, qualification, or buying role.
• It does not treat employment verification as authority verification.
• It does not erase the original reply or suppression after a replacement is found.
• It does not override applicable communication rules or company policy.
9. Common questions
Can we mention the referrer's name in the next message? Only when context, confidentiality, relationship, and policy allow it. A safer default is to use the business-relevant reason for contact, not implied endorsement. What if the referred person is already suppressed? Do not contact them. Preserve the referral as evidence and apply the existing stop state. Does “I forwarded this” count as a positive reply? It is a verified forward statement. It does not prove the receiving person's identity or willingness. Classify it separately from an explicit accepted next action. Should wrong-contact replies qualify the account? They can correct person, role, relationship, or routing evidence. Qualification still requires every active identity/profile and ICP gate; the reply cannot supply unrelated missing facts.
10. Sources and methodology Sources 1 IETF - RFC 5322, Internet Message Format. Used for email message, sender, and thread-evidence context. Accessed August 25, 2026. 2 NIST - Digital Identity Guidelines. Used to distinguish claimed and stronger identity evidence, with explicit limits for referral verification. Accessed August 25, 2026. 3 NIST - Information Quality Standards. Used for bounded source, objectivity, integrity, and correction principles. Accessed August 25, 2026. 4 Federal Trade Commission - CAN-SPAM Act: A Compliance Guide for Business. Used for U.S. commercial-email and opt-out context. Accessed August 25, 2026. 5 Canadian Radio-television and Telecommunications Commission - Canada's anti-spam legislation FAQ. Used for Canadian electronic-message context. Accessed August 25, 2026. SellersGPT analysis and framework The redirect classes, REFER Route Card, replacement procedure, and example are original SellersGPT editorial and product-specific tools. They are not identity standards, legal conclusions, or proof of buyer intent. Update policy Review this playbook when replacement triggers, contact-pool limits, sequence rules, suppression scope, employment states, or applicable messaging requirements change. Audit referred-contact sourcing and retired-person exclusion. Related Knowledge When to Follow Up, Change Contacts, or Stop Place contact replacement inside the wider sequence and stop logic. Choose the route -> How to Classify Email Replies Without Overstating Buyer Intent Identify compound referral, negative, neutral, and stop functions first. Classify the reply -> How to Handle Conflicting, Duplicate, or Stale Signals Resolve outdated employment, duplicate contacts, and contradictory route evidence. Resolve route evidence -> Turn a corrected route into controlled account work SellersGPT preserves the original person's status, referral evidence, account fit, contact treatment, and one owned next action. No subscription. No fixed monthly fee. Pay per qualified lead. Start Building My Pipeline Explore Pipeline Playbooks Editorial illustration brief Asset type: Referral and replacement routing tree Aspect ratio: 16:10 Primary visual: A reply branches into Wrong Function, Departed, Retired, Named Referral, Role Referral, Forwarded, Person Stop, and Company Stop, each with a distinct verification or stop route. Color direction: Warm Ivory and White; Forge Black and Graphite; Signal Yellow for a verified route; muted gray for Unknown; red only for suppression and company stop. Do not use: org-chart guesses, handshake chains, people passing an envelope, robots, AI brains, funnels, fabricated response numbers, or gradients. Alt text: Wrong-contact, referral, forwarded, departed, and stop replies routed through distinct verification rules. Implementation notes
• Render exactly one visible H1 and retain type/topic, read time, and updated date.
• Use Article and BreadcrumbList structured data; do not add automatic FAQ schema.
• Store original-person, account, referral, new-person, suppression, and replacement states separately.
• Block departed and retired contacts from future-round selection; preserve company-stop scope.
• Hide related cards until their targets are published; never emit links to unpublished routes.
Sources and Methodology
- rfc-editor.org: How to Route Wrong-Contact, Referral, and Forwarded Replies
- pages.nist.gov: How to Route Wrong-Contact, Referral, and Forwarded Replies
- ftc.gov: How to Route Wrong-Contact, Referral, and Forwarded Replies
- crtc.gc.ca: How to Route Wrong-Contact, Referral, and Forwarded Replies
- nist.gov: How to Route Wrong-Contact, Referral, and Forwarded Replies
Methodology
This article separates cited official or first-party facts from SellersGPT calculations, examples, frameworks, and recommendations. Source links and scope are retained from the publication pack.
Limitations
This material supports planning and decision-making. It is not legal, financial, regulatory, or performance advice, and it does not guarantee leads, meetings, customers, revenue, or return on investment.