Closed lost, until you ship the thing they asked for

The short answer

What closed lost means

Closed lost is the CRM stage for a deal that ended without a sale. Salesforce and HubSpot both ship a stage by that name in their default sales pipelines, and most teams pair it with a loss reason: price, timing, went with a competitor, no decision, missing feature.

Most closed-lost deals stay closed. A few were never really a no. They were a "not yet" with a reason attached, and the most useful of those reasons is a missing feature, because it is the one your own company can fix. Price objections need a discount. A missing feature needs a merge, and your engineers might already be on it.

Prior art

The two kinds of reactivation play

The batch play. Clay's wake the dead play is the well-known version. Export a year or two of closed-lost deals with their call notes and loss reasons, load them into a Clay table, check that each contact still works there, have a model summarize the old conversation, and send a personalized sequence through Instantly. It runs when you decide to run it. It is a good play, and it is a campaign.

The signal play. Instead of a date, a change triggers the outreach. UserGems' playbook argues for exactly this: re-engage when something observable changed, not after an arbitrary delay. The change can be on their side, such as a new champion or a funding round, or on yours. Clay describes the second kind in its post on how it runs its own closed-lost deals: when a product gap ships, the accounts that cited it surface the same day. Chili Piper made the same point years earlier in its re-engagement ideas, suggesting you pull dead opportunities by loss reason when a launch fills the gap.

This page builds the second one, with the shipped feature as the trigger. It is the narrowest reactivation play there is. That is the point. Every message it sends has a true, specific reason behind it.

The play

The workflow, step by step

1. Make the loss reason a field, not a sentence

A loss reason buried in free-text notes can't trigger anything. Make "Missing feature" a picklist value, and add a second picklist for which feature, required whenever that reason is chosen. Keep the feature list short and owned by someone, or reps will invent a new spelling of SSO every week.

Deal stage:          Closed lost
Closed lost reason:  Missing feature   (picklist, required on close)
Feature needed:      SSO / SAML        (picklist, required for that reason)
Closed date:         2026-04-18
Owner:               the rep who ran the deal

For older deals, a model can read the call notes and suggest a value. Have a person confirm it before it counts. A wrong match here sends a rep to announce a feature the buyer never asked for.

2. Give each feature a way to recognize it shipping

Engineers don't name pull requests after picklist values. So each feature needs a match rule: a few keywords that appear in the PR title or the release copy.

feature_needed     match_keywords
SSO / SAML         sso, saml, single sign-on, okta, entra
Audit log          audit log, audit trail, activity history
Salesforce sync    salesforce, sfdc

If your engineers already label PRs by feature area, labels make a cleaner key. GitHub's REST API lists a PR's labels through the issue labels endpoint, since every pull request is also an issue. Keywords are fuzzier but need nobody on the engineering side to change a habit.

3. Catch the merge

There are three ways to hear about a shipped feature.

The Merge & Tell highlights API. This is the one I built. It reads each merged PR, works out whether a customer would notice it and how big it is, and writes the changelog entry. Ask it once a day what shipped:

curl -H "Authorization: Bearer $MERGETEL_TOKEN" \
  "https://merge.tel/api/v1/highlights?days=2&kinds=feature,improvement&min_magnitude=minor"

Each result carries the title, the classification, and pitch, the copy already written about it, which is the customer-facing sentence your rep needs. Example values, real field names:

{
  "pr_id": "5b0e7c1a-3f2d-4c8e-9a61-0d4b2e7f9c13",
  "repo": "acme/app",
  "number": 812,
  "title": "Add SAML single sign-on for Okta and Entra ID",
  "github_url": "https://github.com/acme/app/pull/812",
  "merged_at": "2026-10-06T15:42:09Z",
  "kind": "feature",
  "visibility": "user-facing",
  "magnitude": "major",
  "confidence": "high",
  "reason": "New sign-in option customers configure themselves.",
  "pitch": "SSO is here. Connect Okta or Entra ID from Settings…",
  "already_promoted": true
}

The changelog feed. If your glue tool only knows how to watch a feed, the same entries are public as Atom and JSON Feed. Each JSON item's external_url is the pull request it came from. n8n's RSS Feed Trigger and Make's RSS module both read them.

https://merge.tel/changelog/<accountId>        Atom
https://merge.tel/changelog/<accountId>.json   JSON Feed 1.1

GitHub's own webhook. GitHub sends a pull_request event when a PR closes, with merged true if it merged. It is immediate and free. It is also every merge, dependency bumps included, with no customer-facing copy, so you write the filter and the rep writes the sentence. Merge & Tell has no outbound webhook of its own, so for push delivery this is the one to use.

4. Join it to the CRM

This step lives in your tools, not mine. For each new highlight, check the match table, then search the CRM for closed-lost deals whose feature matches, closed within a window you pick. Eighteen months is a reasonable start, since past that most contacts have moved or bought something else.

Clay can do it with its HTTP API column and its HubSpot or Salesforce actions. n8n, Zapier and Make can do it with an HTTP step and their CRM apps. In HubSpot itself, a workflow's webhook trigger only enrolls a record that already exists and matches a unique property, so something still has to find the deal ids first.

5. Tell the rep, and let them send it

Create a task for the deal owner with three things attached: the pitch sentence, the PR or changelog link, and the original loss notes. Then let the rep write to the buyer. This is a person they spoke to, about a thing they asked for. A templated blast throws away the only advantage the play has.

One way to build it

An n8n version

Here is the shape in n8n, using its Schedule Trigger and HTTP Request nodes. The same eight steps translate to a Zap, a Make scenario or a Clay table.

1. Schedule Trigger      every weekday at 08:00
2. HTTP Request          GET /api/v1/highlights, the call from step 3
3. Split Out             one item per highlight
4. Code                  match title + pitch against the keyword table, keep feature_needed
5. CRM search            closed-lost deals where feature_needed matches,
                         closed in the last 18 months
6. Remove Duplicates     on deal id + pr_id, so a rerun creates nothing twice
7. CRM create task       for the owner: pitch, PR link, old loss notes
8. Log                   one line per run, including "0 matched"

Step 6 matters more than it looks. The call asks for two days on a daily schedule, so a failed run loses nothing, and that means every highlight arrives twice. Without the dedupe the same rep gets the same task twice and stops trusting every task after it. Step 8 matters too: a run that matched nothing should still say so, or a broken flow looks like a quiet week.

The message

The message the rep sends

Short, specific, and easy to ignore politely. The rep should rewrite it in their own words. It is here to show the shape.

Subject: You asked for SSO

Hi {{first_name}},

When we talked in {{closed_month}}, SSO was the thing that stopped us.
It shipped this week. {{one_sentence_from_pitch}}

If that changes the picture, I can show you the setup in 15 minutes.
If it doesn't, no reply needed.

{{rep_name}}

No "just checking in." No list of seven other things that shipped. The buyer told you one reason, so the email is about that one reason. For the announcement that goes to every customer at once, use the product update email templates instead.

Win-back campaigns

Win-back campaigns in B2B

Search "win back campaign" and you mostly get ecommerce: emails to lapsed shoppers with a discount code. The B2B version is a different animal. There are fewer contacts, each one had a real conversation with your team, and the reason they left is usually written down somewhere. UserGems suggests tailoring each message to the original objection plus whatever changed, over four or five touches in two or three weeks. The feature-gap play is the most literal version of that advice: the objection was the feature, and the change is that it exists.

The same signal works on churned customers who left over a missing capability, and on open deals stuck waiting for one. The product signals guide covers those, and recipe five in GTM workflows covers the everyday version, where sales just hears about every release.

Failure modes

How it breaks

Garbage loss reasons. If reps pick "Other" to close the deal faster, there is nothing to match. This play is mostly a data-hygiene project that happens to end in an email.

Partial ships. SAML for Okta is not SAML for everyone. A keyword match can fire on the first of five PRs. Have the rep read the pitch before they promise anything.

Merged is not live. If your team ships behind feature flags or on a release schedule, a merge can sit for weeks before customers see it. Have the task wait for the deploy, or ask the rep to check the feature is on before they write.

Undersold changes. Merge & Tell's classifier sometimes calls a big change minor. The call above asks for min_magnitude=minor for that reason and lets your match decide what matters.

The contact left. Check employment before the task goes out, the same way the wake the dead play does. A message about SSO to someone who left the company two jobs ago is a bad look.

Honesty

What Merge & Tell does and doesn't do here

Merge & Tell does one job in this play: it notices that a user-facing feature merged and gives you a sentence about it, through its API, its MCP server and its changelog feed. It does not read your CRM, it has no connection to Salesforce or HubSpot, it has no outbound webhook, and it sends no sales email. The loss-reason field, the match table, the CRM search and the message are all yours. I would rather say that plainly than have you find out after you've drawn the diagram.

I also have no numbers on how often this play works, and I am not going to make one up. It is narrow on purpose. Run it for a quarter and count.