One Outlet, Three Inboxes: How to Avoid Duplicate Contacts in Editorial Outreach
A list of unique domains is not enough to coordinate outreach. Learn how to organize contacts, publications, and interaction history to avoid repeated messages without missing legitimate opportunities.
A list without duplicate domains does not guarantee coordinated outreach
Removing duplicates from a spreadsheet of domains solves only part of the problem. One outlet may have several publications, sections, or brands, and one person may receive pitches at different addresses or work for more than one title. If each client or team keeps its own list, a domain may appear only once in each file and the contact may still receive repeated messages. The unit you track needs to be more precise than the domain, while remaining flexible enough not to merge entities that only look similar. The goal is not to prevent two projects from working with the same publication. It is to know what has been done, who is handling it, and whether there are any restrictions before writing again.
- A matching domain is a signal to review, not proof that it is the same contact.
- One person may represent several publications, and one publication may have several points of contact.
- Good deduplication reduces friction and errors; it should not become an automatic block on legitimate opportunities.
What to deduplicate: contact, publication, editorial group, and prior relationship
It helps to separate four entities and link them, rather than storing everything in a single row. The contact is the person or inbox you communicate with. The publication is the specific title, magazine, blog, or section you are pitching. An editorial group may bring together several publications, but they should not all be treated as if they share the same process. The prior relationship captures relevant interactions: messages sent, replies, agreements, pauses, and requests not to be contacted. This distinction avoids two opposite mistakes: writing to the same person several times because they are linked to different publications, or merging different contacts simply because they share a domain. Record the relationships between entities using an internal identifier, and add a brief explanation when the connection is not obvious.
- Contact: a person, role, or generic inbox, along with its communication channels.
- Publication: the name it uses, its domain or section, and known relationships with other titles.
- Editorial group: a useful grouping for coordination, without assuming that it implies a shared policy.
- Prior relationship: activity and instructions linked to the contact, the publication, or both.
Design a minimal record: identity, channel, project, owner, date, and history
The record should make it possible to answer six questions quickly: who was contacted, on behalf of which project, through which channel, who is responsible, when it happened, and what happened next. Start with the fields needed to do the work, and add information only when it has a clear purpose. A small, up-to-date system is usually more useful than an extensive database no one maintains. Keep a person’s data separate from opportunity data. For example, the email address belongs to the contact; the publication and pitch belong to the opportunity. This lets you link records without copying personal data into every project. Also define simple statuses with shared meanings, such as pending review, contacted, in conversation, paused, closed, or do not contact.
- Identity: the person’s name or inbox name and role, if known.
- Channel: the address or professional profile used for the conversation, with a note about its source.
- Project and publication: the context for the pitch, kept separate from the general contact record.
- Owner and dates: the person responsible, last contact date, and next review date, if applicable.
- History: a factual summary of what was sent, the reply received, and the agreed next step.
How to spot variations in names, roles, addresses, and shared details
Matches are rarely perfect. A name may appear with or without an additional surname; a role may change; a person may use a personal address for one title and another, corporate address for a group. There may also be shared inboxes, generic forms, or addresses that forward to a team. For this reason, compare several indicators and keep the source of each detail when it is useful for verification. An approximate match is a reason to review, not to merge records automatically. Check the publication’s name, recent article bylines, contact page, and the context of earlier messages. If the identity is still uncertain, keep the records separate and note the possible connection until it is confirmed. Avoid enriching profiles with personal details you do not need to manage the conversation.
- Standardize capitalization, spacing, and email formats consistently without deleting the original address.
- Compare the name, role, associated publication, and context; do not rely on the domain alone.
- Mark matches as confirmed, probable, or pending, and record who reviewed them.
- Treat generic inboxes as shared channels, not as an identified person.
A pre-contact protocol: search for matches, check restrictions, and assign an owner
Before sending a pitch, check the shared record using the domain, publication name, contact, and known channels. Review not only whether a row exists, but also the history and status: a contact may be in conversation with another owner, have asked for a pause, or have said they do not want to receive further pitches. If a match appears, do not send the message while you are clarifying who is handling the case. Assign an owner and record the decision. If there are no relevant matches, document the check and continue with the usual process. This pre-check should be brief, repeatable, and familiar to every team; it should not depend on the memory of the person searching.
- Search by publication, domain, name, address, and known aliases.
- Review recent activity, replies, agreements, pauses, and requests not to be contacted.
- Check whether another person has an open conversation or an assigned task.
- Assign an owner before writing and record that the check was completed.
- If the identity is unclear, request an internal review instead of sending a test message.
How to handle contacts shared across clients or teams without revealing confidential information
A contact or publication appearing in several projects does not necessarily mean there is a conflict. It may be legitimate to assess opportunities for different clients, provided agreements, expectations of exclusivity, confidentiality, and the contact’s own instructions are respected. Do not assume that a negotiation, price, or relationship from one project can be carried over to another. When teams have different permission levels, coordination can rely on a conflict signal that reveals only what is needed—for example, “there is an active conversation; check with the person responsible.” Access to the client’s name, terms, and conversation content should be limited to those who need it to handle the case. If the situation cannot be resolved without exposing protected information, escalate the decision to the account owner or the person responsible for internal compliance.
- Distinguish an operational match from actual exclusivity or a contractual restriction.
- Share only the minimum information needed internally to prevent duplicate contact.
- Do not reuse pitches, terms, replies, or client data when handling another client’s work without authorization.
- If there are questions about compatibility or confidentiality, hold off on sending and check the applicable agreement.
Rules for recording replies, pauses, and requests not to be contacted
Record facts briefly and neutrally: date, channel, outcome, and next step. Avoid interpretations of the person or comments that do not help manage the relationship. If there is a reply, represent its scope accurately: accepting a specific pitch does not mean accepting others; asking you to write again later does not mean authorizing frequent contact. Requests not to be contacted must become a visible instruction before any new message is sent. Record whom the request applies to and which channel or purpose it covers, to the extent necessary to honor it. Keep only the information needed to maintain that suppression, and apply a review and deletion policy in line with the purpose, applicable obligations, and the organization’s policies. Access should be limited to those managing outreach or compliance with these instructions.
- Use objective notes: “requests follow-up in September” is more useful than a personal judgment.
- Record the scope of a pause or objection so it is not applied ambiguously.
- Make the do-not-contact status easy to check and hard to overlook.
- Review permissions, retention needs, and outdated data regularly.
Frequently asked questions
Is removing duplicate domains from a list enough?+
No. A domain may correspond to several publications or contacts, and one person may manage more than one title. Link domains, publications, contacts, and interaction history without assuming they are the same entity.
Should I merge two records if they have the same domain?+
Not automatically. The domain is a reason to review. Before merging, check the identity, associated publication, and relationship context. If you cannot confirm the match, keep the records separate and flag the possible connection.
How can teams coordinate when they cannot see other clients’ data?+
You can set up a conflict check that shows only whether there is active outreach and who can resolve it, without revealing the client’s name or the conversation’s content. Give access to the details only to those who need them.
What should I do if a contact asks me not to write again?+
Record the request, its date, and the scope needed to honor it, and make it visible before any new actions. Limit access and keep only the information necessary to prevent unwanted future contact.
How should I record a paid editorial collaboration?+
Clearly document the pitch, agreement, and applicable terms. Paid collaborations should be transparent; depending on the circumstances, the link may need to be qualified with sponsored or nofollow, as appropriate. Consult Google’s guidance on qualifying outbound links.
Sources and references
- Google Search Essentials — Google Search Central
- Spam policies for Google web search — Google Search Central
- Qualify outbound links — Google Search Central