---
name: cold-email-outreach
description: "Use when writing a first-touch cold outreach email to a prospect who has had no prior contact — structures it as a specifically personalized opener, one value proposition tied to the prospect's likely pain, and a single low-friction ask kept under ~125 words, instead of a long generic feature-dump with multiple requests. Do NOT use for warm follow-ups to prospects who already replied, replies to inbound support tickets, or bulk marketing newsletters."
metadata:
  decimalai-skill-id: "344aeb0a-fc9d-4c3e-a04f-6eded0e6b63d"
  decimalai-version-id: "541d75f0-1d57-4e33-877b-f59de9e13347"
  decimalai-version: "1"
  decimalai-body-sha256: "c16d3d1686c3e0a17285e1437140cde96732e66d3ea5a183d72151901aa6bc92"
  decimalai-name: "cold-email-outreach"
  decimalai-format: "1"
  decimalai-invocation: "model"
  decimalai-category: "sales-support"
  decimalai-source: "https://app.decimal.ai/s/cold-email-outreach@1/SKILL.md"
---
# First-Touch Cold Email Structure

The email an SDR sends to a prospect who has never heard from them. Base models default to
a long, polite, everything-and-the-kitchen-sink pitch: a throwaway pleasantry, every product
capability listed, and a pile of asks ("book a demo, reply with a time, check out our deck,
happy to loop in your team"). That email gets ignored. A cold email earns a reply by being
short, relevant to ONE thing the prospect cares about, and easy to say yes to.

Write every first-touch cold email in these four moves.

## 1. Open with something specific and true about THEM

The first line proves you know who they are. Reference a concrete detail — their role, a
recent company event (funding, launch, expansion, hiring, a move to a new market), or a
problem their situation implies. It should read like it could only have been sent to this
prospect.

- Never open with a generic pleasantry: "I hope this email finds you well", "I hope you're
  doing great", "Hope you're having a good week." These say nothing and mark the email as a
  blast. Cut them entirely — start on the specific detail.
- One or two sentences. Don't flatter at length; state the observation and move on.

## 2. Make ONE value proposition, tied to their likely pain

Pick the SINGLE most relevant thing your product does for *this* prospect, given what you
know about them, and say it in terms of the outcome they'd care about — not the feature.

- Choose one. If the product does five things, name the one that maps to the pain their
  situation implies. Dumping all five buries the one that matters and reads as a template.
- Frame it as their result ("cut resolution time", "stop losing chargebacks on cross-border
  orders"), not your capability list ("we offer tracing, alerting, and dashboards").

## 3. No feature-dump

Do not enumerate product capabilities. A cold email is not a spec sheet. One outcome,
concretely stated, beats a bulleted list of everything you do. If you're tempted to write
"we also…", stop — that belongs in a later conversation, not the first touch.

## 4. Close with ONE low-friction ask

End with a single, small, easy-to-answer request. One ask, not several.

- Make it low-commitment: a yes/no question or a tiny time cost — "Worth a quick look?",
  "Open to a 15-minute call next week?", "Want me to send a short before/after?" A single
  reply should be able to satisfy it.
- Never stack asks ("reply with times, and check the deck, and let me know who else to
  include"). Multiple asks lower the reply rate; each extra request is a reason to defer.

## Length

Keep the whole email under ~125 words. Short is the point — a cold email is skimmed on a
phone in seconds. If it runs long, the value prop and the ask are the parts that survive;
cut everything else.

## Worked shape

Prospect: a VP of Engineering at a mid-size fintech who just posted several backend hiring
reqs. Product does tracing, error alerting, and cost dashboards. A conforming email:

> Saw you're hiring three backend engineers this quarter — scaling the team usually means
> more services and more 2 a.m. pages before the tooling catches up.
>
> We help fintech eng teams cut mean-time-to-resolution on backend incidents by tracing a
> failing request end-to-end, so a new hire can find the broken service without paging a
> senior engineer.
>
> Worth a quick look at how that'd fit your stack?

Notice: the opener names their specific situation (three backend hires), exactly one value
prop tied to the pain that hiring implies (incidents while scaling), no list of the other
features, one small ask — and it's well under 125 words.