Skip to content
← Processes

Revive deals that went cold

Deals lost more than 90 days ago come back with fresh signals, contacts checked for job moves, and the features they asked for that have since shipped.

Closed-lost is where deals go to be forgotten. The reason for losing gets typed into a dropdown, the thread stops, and eighteen months later nobody remembers that the only blocker was a budget cycle that has since turned over twice, or a feature that shipped last spring. Re-reading them is a job that would take a rep a full day and produce maybe four emails worth sending, so it never gets to the top of anyone's list.

Everything needed is already written down, and it is written down in four different places. The CRM holds the loss reason, the public record holds what has happened at the company since, the profiles hold who is still there, and the issue tracker holds what you have since built. The expensive part is reading two hundred deal histories against four systems to find the eight worth reopening.

What you get

A monthly win-back list where every deal carries what has changed since it was lost, including anything the buyer asked for that now exists, and a draft written from that.

The part worth getting right

The closed-lost reason field is treated as a hint. It is a dropdown chosen at the end of a bad week, and almost everything lands on "price". The thread underneath tells a different story often enough to change the email entirely. "I know price was an issue" is a template. "I know the security review stalled in October" proves somebody read the history.

Step 5 only works if step 2 named the missing capability precisely. "Lost on features" cannot be matched against anything. "Lost because there was no audit trail" can be searched against every issue closed since, and when that search comes back with a release date the win-back has a subject. The thing they walked away over now exists, and you can say when it landed.

A capability that shipped fourteen months ago is handled differently from one that shipped last week. The recent one is news. The old one is an admission that nobody told them at the time, and the email is better for saying so plainly than for presenting a year-old release as though it just happened.

Deals where nothing has changed get dropped, which keeps this off the quarterly-blast list. The instinct is to write to everyone, because the list is right there and the drafting is free. These are accounts that already said no once, though, and a second contact with no new information is how a domain's reputation gets spent. Counting the drops rather than hiding them keeps that visible.

The most valuable output is often not the win-back at all. A champion who has moved to a company you already hold is a warm introduction at that account, and they surface because the contact check runs before the drafting. Teams that run this monthly tend to find those are worth more than the deals they reopened.

The prompt

The real prompt behind the steps above — detailed enough that an agent with a people-search tool, email/phone enrichment, and CRM access can run it as written.

# Revive deals that went cold

You have access to a CRM, a scraping tool, a professional network, an
issue tracker, email, and a messaging tool. Run this monthly across
**[deals marked lost more than 90 days ago]**.

## 0. Set up (skip if you're already connected)

If you don't already have live tool access for this, connect it
first. This prompt is only as real as the tools behind it:

1. Create a free account at app.tulina.ai.
2. Add Tulina's MCP server to your assistant: https://mcp.tulina.ai/mcp
3. In Tulina, connect your own API keys for the tools this
   prompt uses: your CRM, a scraping tool, a professional network,
   your issue tracker, your email, and your team's messaging tool.

Once connected, your assistant has real tool access and the rest of
this prompt runs as written.

## 0b. Already on Tulina? Three things around the run

An account and the MCP server are not the whole setup. Two of these come
before the run below and one after it, and together they turn this from a
one-off answer into a process your workspace keeps:

1. **Activate this process's connectors first.** Call
   `oto_connector(op="list")`, match it against the tools named in step 3
   above, and `oto_connector(op="select", name="...")` every one that
   isn't active yet. Selecting a connector does not mount its tools in the
   conversation you're already in — reach them through `oto_call` for this
   run, or open a fresh conversation once they're all on.
2. **Attach the work to an existing project.** `oto_project(op="list")`
   shows your active org's projects: pick the one this work belongs to
   rather than opening another, and keep its id. The project is where this
   process, the tables it writes to and the connectors it uses hang
   together.
3. **When the run is done, save it as a process — with its graph.** Write
   the body with `oto_procedure(op="set", ...)`, then attach it with
   `oto_project(op="link", project_id=..., target_type="procedure",
   target_ref="<your slug>")`. The body has to carry a drawing: read
   `oto_guide(op="read", slug="procedure-flowchart")` and follow it
   exactly — ONE untagged fenced block in that grammar, opening with the
   trigger and a quoted example of what you'd type to start a run. Tulina
   parses that drawing back into the graph it renders as the process's
   default view, which is what makes it come out in the same style as
   every other process in the app; a drawing the grammar can't read falls
   back to raw characters instead. Saving a process needs org-admin
   rights — without them, hand the finished body to someone who has them.

## 1. Pull deals lost more than 90 days ago

Ninety days is the floor. Inside it the reason for losing is almost
always still true, and the email reads as not having listened.

Put a ceiling at twenty-four months as well. Past that the people
involved have moved on and this is a cold email wearing a follow-up's
clothes.

Exclude outright:

- Deals lost to a competitor on a multi-year contract that has not yet
  expired. Check the term if it was recorded.
- Anyone who asked not to be contacted again.
- Accounts with an open opportunity right now.

## 2. Establish why each one was lost

Read the deal's full history: notes, logged calls, the email thread,
and the closed-lost reason field. The field alone will not do. It is a
dropdown someone picked under time pressure, and "price" often turns
out to mean "no budget this year" or "could not get the security
review through".

Classify each into one of four, and record the evidence you used:

- Timing or budget.
- A missing capability, with the specific capability named. Step 5
  depends on this being precise.
- Lost to a competitor.
- No decision, went quiet.

## 3. Pull fresh signals from the company

Look for what has happened at the company since the loss, with a date
on each item:

- Hiring, especially for the function you sell into. A posting is
  dated, public, and someone at that company approved it.
- Funding, acquisition, a new office, a new market.
- Leadership changes in or above the buying role.

Keep the source URL for anything you plan to reference. A win-back
that cites something the reader can go and check is a different
message from one that gestures at momentum.

## 4. Check whether the contacts are still there

Verify each contact against their public profile before writing
anything. Three outcomes matter:

- Still there. Write to them.
- Gone, with a replacement findable in the same role. Write to the
  replacement, and never open by referencing a conversation they were
  not part of.
- Gone to a company already in your CRM. That is a warm introduction
  at the new account, which is frequently worth more than the win-back
  itself. Flag it separately.

## 5. Check what has shipped since

For every deal lost over a missing capability, search the issue
tracker for what has been released since that deal closed.

Match on the substance of what they asked for, not on their wording. A
buyer who wanted "a way to see who changed what" and a shipped issue
titled "audit log" are the same thing, and a literal match will miss
it.

Record the release date. A capability that shipped last week is a
reason to write today; one that shipped fourteen months ago raises the
question of why nobody told them at the time, and the email should
acknowledge that rather than pretend it is news.

## 6. Weigh it together and decide who is worth writing to

Now put the four inputs side by side for each account: the original
loss reason, the fresh signals, the contact situation, and anything
that has since shipped.

A deal is worth reopening when the loss reason has been answered by
one of the others:

- Lost on a missing capability, and that capability now exists.
- Lost on timing or budget, and there is a funding round, a new fiscal
  year, or a new person in the buying role.
- Lost to a competitor, and their contract is near its renewal window.
- Went quiet, and the person who went quiet has been replaced.

Where nothing answers the loss reason, drop the deal and count it. A
win-back with nothing new to say is how a sender gets marked as spam,
and these accounts already said no once.

## 7. Draft, and post the batch for review

One email per account: what happened, what changed, one question.

Reference the original conversation specifically, including roughly
when it was. Name the change plainly. If a capability shipped, say
what it does rather than promising "exciting updates".

Draft it, do not send it. Then post to the team channel: how many
deals were in scope, how many were dropped and why, and the drafts
grouped by loss reason so whoever owns the account can scan their own.

## Output

Report: deals in scope, dropped by exclusion rule, dropped for nothing
having answered the loss reason, contacts that had left, champions
found at accounts you already hold, capabilities matched to shipped
work, and drafts written.

Questions about this process

Inside ninety days the reason for losing is usually still true, so the email reads as not having listened. There is a ceiling too, at twenty-four months, past which the people involved have moved on and it is a cold email pretending to be a follow-up.

The loss reason records the specific capability, and the issue tracker is searched for released work matching it by substance rather than wording. A buyer wanting "a way to see who changed what" and a shipped issue called "audit log" are the same thing.

The deal is dropped from that run and counted. A win-back with nothing new to say is the message that gets a sender marked as spam, and the point of the process is to write only where there is something to write about.

Their replacement in the same role is written to instead, and never with an opener referencing a conversation they were not part of. If the champion moved to a company already in your CRM, that is flagged separately as a warm introduction there.

Related processes

  • Prepare for a customer call

    Before the call, the last conversations, the account's state, how the product is actually being used, and where their requested features stand, in one brief.

  • CRM hygiene and prospect job changes

    Duplicates merged and broken fields repaired on a weekly schedule, with prospects who changed employer followed to their new company and a recap posted to the team.

  • Prepare for a demo from the last call

    The last calls, the deal's state, and fresh research become one prep brief, plus a deck built around that company's own use cases, posted before the meeting.

Experience Tulina for 14 days.

By continuing, you agree to our Terms of Use and Privacy policy.