Double opt-in introductions: a practical guide for connectors

A double opt-in introduction means each person agrees to a specific connection before the connector sends a shared message. Check interest separately, confirm what context may be shared, then introduce the people with a clear reason to talk. An unanswered request is still unanswered. It should not be treated as permission to add someone to an email thread or book a meeting.

This guide is for the connector managing that process. If you are the person asking to meet someone, start with our guide to getting a warm introduction. A strong request makes your situation understandable; a good connecting process gives the other person a genuine choice. The two responsibilities fit together, but they are not the same task.

What exactly are both people agreeing to?

Be specific about the proposed introduction. Identify the other person, the reason a conversation may be useful and the kind of next step being suggested. Agreeing to meet an operator about a workflow question is not the same as agreeing to review a pitch, become an adviser or receive an ongoing sequence of requests.

In his original discussion of double opt-in introductions, Fred Wilson recommends checking with each person before connecting them. This is professional etiquette advice, not a claim that a particular message format guarantees a response or a useful relationship. The practical notes below are original examples of how a connector can apply that principle.

Keep the purpose visible when a request changes. If an exploratory conversation turns into a proposal to recruit the person, ask whether that new conversation is welcome rather than relying on an earlier yes. A connector's value comes partly from accurate context. Treating every positive response as permission for a larger ask can make the introduction misleading.

Start by understanding the requester's actual need

Ask what the requester is trying to learn or do, why this person is relevant and what they can share to make the conversation concrete. You do not need to investigate the entire business. You do need enough understanding to decide whether you are comfortable presenting the request and what you can honestly say about the person making it.

For a hypothetical founder looking for technical judgment, the immediate request might be to discuss a difficult integration choice. That does not necessarily mean the founder is recruiting a partner. If the real goal is a technical cofounder search, make that context explicit before asking someone to meet. Different purposes deserve different decisions from the recipient.

Ask the requester for a short note you are allowed to pass along. thoughtbot's introduction-request guidance provides examples grounded in relevant context. Use the principle without borrowing anyone else's relationship history. If you have not worked with the requester, do not write that you can personally vouch for their execution.

Ask the proposed recipient without creating pressure

Send a separate, bounded request before putting the people into the same thread. Name the person, explain the proposed topic and offer an easy way to decline. Avoid attaching a calendar invitation or telling the requester that the meeting is effectively arranged. You are checking interest, not announcing a decision the recipient has already made.

Here is an original hypothetical note from a connector who has actually reviewed the work mentioned. It is an example to adapt, not a statement about an AME member or a real introduction.

A founder I know is exploring a scheduling workflow for independent service teams. I have seen their demonstration, and they are trying to understand how operators handle changes after a job is assigned. Your experience looks relevant. Would you be open to an introduction for a short conversation about that problem? There is no issue if the topic or timing does not fit.

Use an accurate description of your relationship and remove any claim you cannot support. If you only know the person's public work, say that. If you do not know whether their request fits the recipient's expertise, present it as a question. Precision is more useful than making the request sound warmer than the relationship actually is.

Confirm the requester and the shareable context

The requester may already have agreed to this introduction in a clear original message. Do not create unnecessary ceremony, but confirm the boundaries when they are unclear. Ask whether the recipient's proposed topic or availability works and whether the short note remains accurate. A changed business situation can make an old introduction request no longer relevant.

An original permission check might explain that the recipient is open to discussing a particular operations question, then ask whether the requester wants the introduction on that basis. Identify the paragraph or link you intend to share. Keep the recipient's private explanation out of the message unless they specifically agreed that it could be passed on.

Keep sensitive background separate from the introduction itself. A job search, unresolved commercial issue or confidential project may have helped you understand the request without being appropriate to forward. Use a version of the context both people expect to see. Do not assume that permission to share a summary also covers private attachments or the complete history of your conversation.

Send a shared message that stands on its own

After both people have agreed, introduce them in a new message or a suitably trimmed thread. Say who each person is, why you thought the conversation could help and what topic they agreed to explore. Use the wording you can support. You are providing context for a conversation, not guaranteeing competence, commercial results or a future partnership.

For an original hypothetical shared note, identify the founder exploring the workflow and the operator who has handled that kind of handoff. State that both agreed to connect about the specific question. Mention any demonstration they have agreed to share. Then leave the next step with the participants rather than continuing to direct their conversation as if you were managing a project.

Consider whether each link and attachment belongs in this first shared message. A long deck can change a modest discussion into a review assignment. If more material would be helpful, let the participants agree on that exchange themselves. Keep your description of the original request consistent with what each person accepted separately.

What should you do when someone declines or stays silent?

If either person declines, close the request without making the other person argue the decision. You can say the introduction will not proceed. Do not reveal a private explanation, speculate about motives or offer a different route to the same person without checking whether further contact is wanted. A respectful refusal leaves the relationship intact without inventing a reason.

If a message goes unanswered, treat the state as pending rather than accepted. Depending on your relationship, a brief check may be reasonable, but do not turn a favor into a repeated pressure campaign. Keep the requester informed that you have not received agreement. They should not be planning around a meeting that exists only in their assumptions.

If the requester wants you to connect someone else instead, evaluate that as a new introduction. The new recipient may have a different role or context, and the original person's permission cannot answer for them. Keeping a simple note of whom you asked, the topic and the reply can help you avoid overlapping requests without building an unnecessary dossier.

When is the connector's job finished?

Once the agreed introduction is made, let the participants handle their conversation. A short private update can help you know whether they connected, but avoid requiring details they have not chosen to share. If the exchange might lead to a founding partnership, our cofounder trial guide describes a later evaluation step. An introduction itself does not establish that the people should work together.

AME learns what people are building and what they need next, then makes purposeful introductions one at a time. You can learn about AME or apply for AME 1000. In any introduction process, give both people accurate context and a real choice. A useful connection begins with agreement about the conversation, not a promise about where it will lead.