A “do not contact” request must survive project changes
A practical protocol for distinguishing a one-time rejection from a request for no further contact, recording only what is necessary, and preventing another project from reaching out by mistake.
Not replying, rejecting a pitch, and asking you not to write again are not the same thing
In editorial outreach, classify a response according to what the person has communicated, not what the team assumes. Silence does not express a contact preference: it can have many causes and does not allow you to conclude that the person has declined. “This pitch isn’t a fit for us” rejects that pitch, but not necessarily future contact. By contrast, phrases such as “don’t contact me again” or “remove me from your list” are explicit requests for no further contact and should be treated as such. If a message is ambiguous—for example, “I’m not interested” with no further context—do not automatically turn it into a permanent ban or use it as an excuse to keep pushing. Record the rejection of that specific pitch and apply a reasonable pause in line with your process. If the person explicitly asks not to be contacted, do not write back to ask for clarification: respect the request and resolve it internally.
- No reply: there is no explicit preference to record as a do-not-contact request.
- One-time rejection: drop the pitch or topic they indicated; do not assume this gives you permission to keep trying with another offer.
- Explicit request: block further contact within the stated scope, even if the project, client, or team member in charge changes.
Record only what is needed to make the instruction clear
A restriction only works if the next person in charge can tell who it applies to and what to do. Keep only the operational details needed to identify the contact and apply the preference: a reliable identifier for the person or channel, the scope of the request, the date, the channel through which it came in, and a clear status such as “do not contact.” If the person’s identity is unclear, add an internal note to verify it before sending anything. Include a brief, accurate summary of the reason or relevant wording only when it is needed to interpret the scope. Avoid copying entire conversations, attachments, irrelevant personal data, or confidential campaign details. The purpose of the record is to prevent unwanted contact, not to build a file on the person.
- A sufficient identifier to avoid confusion, such as the relevant email address or professional contact details.
- The scope of the restriction: channel, area, or general request, if it is clear.
- Date, channel of receipt, status, and the team member who recorded the request.
- A brief context note only if it is needed to apply the instruction without arbitrary interpretation.
Build the request into the workflow, not one person’s memory
Choose a single source of truth for contact restrictions and a simple process for updating it. When a request comes in, the person who receives it should record it promptly, stop any pending outreach that could reach the person, and notify the person coordinating outreach. The restriction must then be applied to active work lists too; it should not remain in a private note or email history. You do not need to keep excess information to preserve the preference. If the record is no longer needed, follow your internal data retention and deletion criteria without deleting it in a way that could accidentally put the person back on an active list. Operationally, when necessary to prevent contact, keep a minimal suppression signal, with limited access and periodic review.
- Record the request in the agreed repository and confirm that its status is visible to authorized team members.
- Remove or block the contact from active outreach tasks and lists.
- Avoid duplicate records and scattered free-form notes that could contradict the main status.
- Limit access to staff who need to apply the restriction.
Share the restriction across teams and projects without oversharing
At an agency, a person may appear in several research efforts or campaigns. A change of client, project, team member in charge, or list must therefore not restart the check. The restriction should be available wherever outreach is prepared, without requiring disclosure of other clients’ commercial context. Separate the information needed to prevent a message from campaign-specific information. For example, the team needs to know that the contact is excluded and the scope recorded; it normally does not need to know another client’s budget, strategy, or confidential details. Assign someone to maintain the record and establish how updates are carried over to work lists.
- Set a shared source of truth for teams that conduct outreach.
- Share the status and scope needed—not another project’s file.
- Include the check when adding new lists and when the person in charge changes.
- Do not try to get around the request by using another sender, account, or channel.
Check the restriction immediately before every contact
Verification should not depend on the person preparing the message remembering an earlier conversation. Before sending, check the recipient against the exclusion record, including contacts added from new lists and scheduled messages. If there is a match, do not send, and make an internal note that the check was applied. If the record is ambiguous, incomplete, or might refer to the same person, do not proceed by default. Pause the contact and ask for an internal review. Do not write to the person to resolve a question caused by your own lack of information, especially if the request could be a do-not-contact request. If the details are not enough to confidently distinguish between two contacts, resolve that uncertainty before starting outreach.
- Check before preparing each send, not only when creating the list.
- Include individual messages, follow-ups, and outreach from different projects.
- If there may be a match or the scope is unclear, pause and escalate internally.
- If a message is sent by mistake, stop further contact and document the incident so the process can be corrected.
Review the protocol without turning exceptions into permission to keep trying
A useful protocol should be reviewed periodically and when tools or responsibilities change. Check whether active lists consult the shared source, whether ambiguous records are resolved before messages are sent, and whether opt-outs carry across projects. The review should improve the process, not justify new attempts to make contact. Document exceptions narrowly. If the person starts the conversation again or clearly says they are open to receiving a specific pitch, record that change with its date and scope; do not interpret it as general permission for any campaign or channel. Keep this preference separate from editorial terms: if a collaboration is paid, handle that transparently, and qualify links appropriately for the circumstances—for example, with sponsored or nofollow attributes where applicable. This is an operational protocol and does not replace a legal or privacy review when one is needed.
- Review access, duplicates, lists, and update rules at a frequency set by the team.
- Note who approved a change in scope, when, and for which specific contact.
- Do not treat later silence, a new project, or a limited exception as permission to keep trying.
- Keep contact controls separate from transparent handling of an editorial collaboration.
Frequently asked questions
Should a lack of response be recorded as a do-not-contact request?+
No. Silence alone does not express a do-not-contact preference. Treat it as no response and follow your established outreach process, without confusing it with an explicit rejection.
What is the difference between rejecting a pitch and asking not to be contacted again?+
A rejection may apply only to the pitch received. An explicit no-contact request means no further messages should be sent within the scope communicated. If the wording is ambiguous, pause and review the case internally.
What should a team share across projects?+
Only what is essential to prevent contact: a reliable identifier, the exclusion status and its scope, and the minimum information needed to interpret it. There is no need to disclose other clients’ budgets, strategies, or confidential details.
Can you contact someone again if their project or point of contact changes?+
A change of project or person in charge does not cancel an active request. Record a change only if the person starts the conversation again or clearly communicates a change in preference, and limit that change to the scope they expressed.
Sources and references
- Google Search Essentials — Google Search Central
- Spam policies for Google web search — Google Search Central
- Qualify outbound links — Google Search Central