Skip to content

How-to

How to Ask for a Warm Introduction: Email and Message Templates

Most people who could make an introduction request either never send one or write a message so vague the connector has to do all the work themselves. The email model, the LinkedIn DM format, the Slack variant, and the one variable that determines whether the connector says yes.

The introduction request is not the same as the introduction itself. The connector writes the introduction: the email that goes to the person you want to meet. You write the request: the message that asks the connector to make the introduction in the first place. These are different messages, written by different people, for different purposes. Most advice on warm introductions focuses on the introduction email. The request message gets less attention, which is why most people either never send one or send something so vague it puts all the interpretive work on the connector.

The mechanics of the request message are specific to the channel it travels through. An email ask has more space and can carry a subject line; a LinkedIn DM operates under character constraints and a more informal register; a Slack message inside a shared workspace can be shorter still because shared context already exists. This guide covers all three, plus the double opt-in check for cases where you are not certain whether the connector will be comfortable making the introduction.

Message templates by channel

The email ask

Use when the connector is a professional contact you email regularly, or when the introduction itself will travel by email.

The email ask follows a three-sentence model: the hook (why you thought of this connector specifically), the specific outcome (what you want them to say about you, not just that you’d like to meet someone), and the easy out (a low-friction way to decline). The hook matters because it signals that you’ve done the relational work of thinking before asking. "I thought of you because you know the head of BD at Acme" is meaningfully different from "I thought you might know someone at Acme". The first shows you’ve matched the ask to the relationship; the second puts the connector in the uncomfortable position of deciding whether their relationship is strong enough to introduce. A concrete example of the three-sentence model: Subject: Introduction to [Name] at [Company] (would you be up for it?) "Hi [Connector], I’ve been trying to reach [Name] at [Company] about [specific topic], and I remembered that you two worked together at [context]. Would you be willing to make a quick introduction? Here’s a short blurb I’ve drafted to make it easy. And completely fine to say no if the timing isn’t right." The blurb (your forwardable brief) goes directly below or in an attachment. The subject line names the outcome rather than the action ("Introduction to [Name]" rather than "A favour") because it lets the connector immediately assess whether this is a reasonable ask before opening the email.

The LinkedIn DM ask

Use when the connector primarily communicates on LinkedIn, when the introduction will also travel through LinkedIn, or when your email relationship with them is thin.

The LinkedIn DM format is constrained by character limits and context. The connector is reading in a professional feed, often on a phone, alongside dozens of other messages. The model collapses to two parts: the context hook (one sentence, specific) and the ask (one sentence with the graceful exit built in). Drop the background. Drop the explanation of why you want the meeting. Lead with why you thought of them specifically. Example: "Hi [Connector], you know [Name] at [Company] better than almost anyone I’m connected to. Would you be willing to send a brief introduction? Happy to send a blurb you can forward directly." The offer to send a blurb does two things. It signals that you’re not going to make them write the introduction themselves, which is the silent fear behind every declined intro request. And it establishes that the ask has a specific, bounded scope: forward one message, close the loop. What not to do on LinkedIn: write the full email-length ask as a DM. The platform signals informality; a long, structured message reads as out of place and often gets skipped over. If the ask is complex enough to need a full explanation, it belongs in email. LinkedIn DMs are for simple asks to connectors you know well enough that the context is already shared.

The Slack or Teams message ask

Use when you share a Slack workspace or Teams channel with the connector: typically a colleague, a community member, or someone in a shared professional group.

Slack and Teams messages operate on an informal register. The ask can be shorter than email, less structured than a LinkedIn DM, and it often happens in a thread rather than a DM. The key difference from external channels: the shared workspace means the connector already has a lot of context about who you are and what you work on. You can drop the hook almost entirely. Example: "Hey [Connector], do you know anyone at [Company] who works on [area]? Would love an introduction if so. Happy to send a brief blurb." In a community Slack (where the connector is a fellow member rather than a colleague), add one sentence re-establishing the relational context if you’ve only interacted in threads rather than directly: "We met in #[channel] a few months back. I’ve been following your posts on [topic]." This isn’t a formal hook; it’s a reminder that you’re not a cold stranger. One Slack-specific caution: avoid asking in a public channel unless the community has an established norms for introduction requests (some do, usually marked with a channel like #intros or #ask). Most community connectors prefer to handle these in DMs, where the conversation can be more candid about whether the relationship is strong enough to carry the introduction.

The double opt-in check

Use when you are not certain whether the connector will be comfortable making the introduction, either because the relationship may be thinner than you think, or because the request is sensitive.

The double opt-in check is a pre-ask: you verify that the connector is willing to make an introduction before you attach the forwardable brief and make the full request. It keeps the connector in control throughout the process, which matters both ethically and practically: a connector who feels rushed into an introduction will either decline or make an unenthusiastic one. The check follows a two-message sequence. The first message asks whether the connection exists and whether the connector would be open in principle: "Hi [Connector], I’ve been trying to reach [Name] at [Company] about [topic]. Would you be comfortable making an introduction, or is that not a natural fit for you to do?" If they say yes, the second message sends the forwardable brief: "That’s great. Here’s a short blurb you can forward directly. And thank you, genuinely appreciate it." If they say no or express hesitation, the conversation closes without either party feeling uncomfortable. Mark Granovetter’s research on relationship strength predicts that the threshold for yes scales with how strong the connection is: close colleagues will often say yes to a brief check message without needing to see the brief first; loose acquaintances need more context before committing. The double opt-in structure adapts to both: it keeps the initial ask small and lets the connector set the pace of the interaction.

What all four formats have in common

Across email, LinkedIn, Slack, and the double opt-in check, the effective request message does four things: it specifies the person you want to meet (not just the company or the function), it states what the introduction is for (the subject of the first conversation, briefly), it gives the connector a way to forward the introduction without having to write anything themselves (by offering a blurb), and it gives them a low-friction way to decline.

The research on connector decision-making points to specificity as the strongest predictor of yes. Schmitt and Van den Bulte’s work on referral trust transfer finds that a vague ask puts the connector at risk of overstating their relationship with the target. They can’t calibrate whether the vouching the request implies is accurate unless the ask is specific. When the request is precise about who, why, and what the conversation is for, the connector can assess quickly whether they can legitimately carry it. That assessment is the gateway between ask and introduction.

Robert Burt’s research on network brokerage positions shows that connectors with strong bridge relationships, the ability to introduce people across different social clusters, are the highest-value connectors. But the same research shows that those connectors are also the most selectively protective of their relationship capital. They say yes readily to well-scoped, specific asks; they say no or go quiet on vague asks that could consume relationship credit without a defined return. Calibrating the ask message to match the specificity of the outcome is what keeps high-value connectors in the pool.

Three failure modes in the ask message

The vague outcome

The most common failure: asking to be "connected with someone" without specifying what the introduction is for. "I’d love to get connected with someone at Acme" forces the connector to do all the interpretive work: figure out who, assess whether the relationship is appropriate, and guess what kind of brief to write. A specific request ("I’m trying to reach [Name], the head of BD, about [topic]") does that work for them and signals that the ask is grounded rather than speculative. Schmitt and Van den Bulte’s research on referral trust transfer shows that specificity in the introduction request is a strong predictor of whether connectors follow through. A vague ask puts their relationship at risk because they have no way to calibrate whether they’re over-vouching.

Front-loading context

A long introduction before the ask. Three paragraphs explaining the product, the company, the market, and the problem before ever saying who you want to meet. By the time the connector reaches the actual ask, they’ve spent enough reading time that saying yes feels like a significant commitment. The model is the opposite: put the ask in the first sentence, the context in the second, and the graceful exit in the third. Connectors are making a quick calculation: is this ask reasonable, does my relationship support it, is the timing right? A short message lets them answer those questions efficiently. A long one forces them to hold context while they read, and most will defer the decision until later, which in practice often means never.

Missing the graceful exit

Not giving the connector a clear, low-friction way to say no. When a message creates social pressure to say yes (either by implying the requester has been waiting a long time, or by not leaving any opening for a decline), connectors often go quiet rather than respond with a no. The silence is worse than a no: it leaves the requester in uncertainty and creates awkwardness the next time the two people interact. A sentence like "completely fine to say no if the relationship isn’t quite right" or "only if it’s a natural fit" is not politeness filler. It’s a functional mechanism that makes yes more likely by making no easier. Cialdini’s research on reciprocity shows that lowering the barrier to refusal paradoxically increases compliance rates.

Calibrating the ask to relationship depth

The template structure stays the same across close and moderate relationships; what changes is the tone and the amount of context you need to re-establish. With a close connector (someone you’ve spoken to in the last six months, who knows your work well), the ask can go straight to the specific request. The hook is almost unnecessary: they already have the context. The message can be two sentences.

With a moderate connector, meaning someone you’ve met several times, have a genuine relationship with, but haven’t been in close contact with recently, the hook matters more. One sentence that acknowledges the specific context you share is enough: a project you worked on together, a conversation you had at a conference, a piece of work they did that you followed. This is not empty pleasantry. It is evidence that the relationship is a real one, which is the factor the connector is assessing when deciding whether their vouching would be credible.

With a dormant relationship, someone you knew well but haven’t been in touch with for over a year, acknowledge the gap briefly before the ask. Not as a long reconnection attempt, but as a single sentence: one that signals you are aware that you’ve been out of touch and are not treating the relationship as a purely transactional resource. The rest of the ask message stays the same.

FAQ

FAQs on introduction request templates

How long should the ask message be?

Short enough to be read in one glance. Email: three sentences plus the forwardable brief. LinkedIn DM: two sentences. Slack or Teams: one to two sentences. The principle is to compress the message to the minimum the connector needs to make a yes-or-no decision. Background context, market explanation, and product details belong in the forwardable brief that you send after they agree, not in the ask itself. The ask message’s job is to get to yes; the brief’s job is to make the introduction easy to send.

Should I attach the forwardable brief in the first message?

Only if you’re confident the connector will say yes. If you have a strong, close relationship with the connector and the ask is clearly within scope, including the brief immediately saves a round trip and makes it even easier for them to act. If you’re less certain (the relationship is moderate, the ask is sensitive, or there’s any chance the connector would hesitate), use the double opt-in check first. Sending the brief before you’ve confirmed they’re willing can create the impression that you’ve already committed them to something they haven’t agreed to, which is a form of social pressure that tends to produce either an uncomfortable yes or a sudden non-response.

What if I haven’t spoken to the connector in over a year?

Acknowledge the gap before making the ask. A dormant relationship where you lead directly with a request signals that you only make contact when you need something, which is exactly the transactional pattern that erodes connector relationships. One additional sentence before the ask, acknowledging the time and briefly reconnecting, changes the dynamic: "I realised I haven’t been in touch since [context]. Hope you’re doing well." The rest of the ask stays the same. The acknowledgment is brief; its purpose is not to over-engineer the reconnection but to signal that you’re aware of the gap and are not treating the relationship as a purely transactional resource.

How do I follow up if the connector doesn’t respond after a week?

One follow-up, after five to seven business days, is appropriate. Keep it short, a one-sentence bump that refers to the original message: "Bumping this in case it got buried. Happy to send the forwardable brief whenever is convenient." If there’s no response after the follow-up, let it rest. Repeated follow-ups after two touches create social pressure that damages the relationship more than the introduction would have helped. The connector may have a good reason for the delay that isn’t visible to you. A third message almost never produces a yes and often produces a decline by silence that persists across future asks.

Can I ask for more than one introduction at once?

To the same connector: one introduction per ask message. Asking for three introductions in a single message ("can you connect me with [Name 1], [Name 2], and also [Name 3] at Acme?") multiplies the social risk the connector is taking on and makes it harder for them to say yes to any of them. Each ask should be a separate conversation. If you need multiple introductions from the same connector, space the requests out. The first one, if it goes well, increases the probability that the second request will land positively, because you’ve demonstrated that you follow through, loop the connector back in, and don’t over-use the relationship.

Make it easier for connectors to say yes

LetsBridge gives you the infrastructure to find the right connector, send a precise ask, and follow up without friction, so the mechanics of the request work as well as the relationship behind it.