Post a new customer brief to Slack when a deal closes
Images on this page are for illustrative purposes only. Example outputs in this play are illustrative — the structure, fields, and format reflect real Lusha connector and Gmail thread output, but were not pulled from a live session. Run the prompt with your own data and connectors to see live results. Personal details in any live examples are masked or abbreviated for privacy.
CS teams usually start a new customer relationship with a 30-minute debrief from the AE — if one even happens. This Claude prompt posts a structured handoff brief to Slack the moment a deal closes. Gmail pulls what the customer said the problem was and every promise made during the sales process. Lusha validates the full contact map at the account and checks for early expansion signals. CS starts informed. The AE moves on. No debrief required.
The prompt
This prompt may contain placeholders — look for [BRACKETS] and fill them in.
<context>
A deal just closed. Before the AE moves on and CS starts from scratch, I want a structured new customer brief posted to our CS Slack channel — who the contacts are, what was promised during the sales process, what the expansion signals look like already, and everything CS needs to start the relationship without asking the AE to debrief manually.
The deal:
- Company: [COMPANY NAME]
- Deal value: [ACV]
- Primary contact: [NAME AND TITLE]
- AE who closed: [AE NAME]
- CS owner: [CS MANAGER NAME OR "assign from channel"]
- CS Slack channel: [CHANNEL NAME — e.g. #customer-success or #cs-handoffs]
</context>
<task>
1. Use Lusha to validate and map all known contacts at this account:
- Primary contact: confirmed title, verified email, direct phone
- Any other contacts at the account from the sales process: map their roles
- Check for any new stakeholder who joined during the sales cycle but wasn't the main contact
- Run a signals check: any structural change at the account in the last 60 days
2. Search Gmail for the full sales thread with this account:
- What problem did the customer describe in their own words?
- What was promised during the sales process — demos, integrations, onboarding support, intros?
- Any concern or objection raised but not fully resolved before close?
- Any competitor mentioned during the evaluation?
- What was the stated reason for choosing us?
3. Build the new customer brief and post to the CS Slack channel:
Format — one structured post, *bold* key fields:
*New customer: [Company] — [ACV] — Closed [date]*
*WHO'S IN THE ACCOUNT*
All verified contacts with current titles, emails, and roles in the buying process
*WHAT THE CUSTOMER SAID THE PROBLEM WAS*
In the customer's own words — not a paraphrase
*WHAT WAS PROMISED*
Every commitment made during the sales process that CS now owns
*OPEN CONCERNS*
Any objection or concern raised but not resolved before close
*EXPANSION SIGNALS*
Any Lusha signal suggesting early expansion potential
*COMPETITOR MENTIONED*
Any alternative the customer evaluated
*SUGGESTED FIRST ACTION FOR CS*
One specific action for the CS owner in the first 48 hours
4. Tag the CS owner and the closing AE in the post.
</task>
<constraints>
- Post to Slack. This is a live handoff, not a document.
- WHAT THEY SAID THE PROBLEM WAS must be in the customer's words, pulled from Gmail.
- WHAT WAS PROMISED is a checklist CS owns from day one — every item must be specific.
- If Gmail shows no thread, flag it — the AE needs to forward the relevant history before CS starts.
- Tag both the CS owner and the AE — the AE is accountable for anything on the promises list.
</constraints>What you'll get back
The situation: Waverly Digital just closed at $72K ACV. Sarah is the closing AE. The CS manager is Marcus. Running the prompt immediately after the deal is marked closed-won.
Slack post — #cs-handoffs
🎉 New customer: Waverly Digital — $72K ACV — Closed May 27 · @marcus.cs @sarah.ae
WHO’S IN THE ACCOUNT
S.R., VP of Sales — s.r@[waverly].com ✓ · mobile available · Primary contact, economic buyer, signed the contract D.K., Head of Sales Operations — d.k@[waverly].com ✓ · mobile available · Technical evaluator, day-to-day implementation owner Unknown attendee from the May 14 demo — email unverified, identity unconfirmed · @sarah.ae — who was this?
WHAT THE CUSTOMER SAID THE PROBLEM WAS
“New SDRs are taking 6+ weeks to ramp because the team is building lists manually. We need the data layer to already exist when a new hire starts.” — S.R., discovery call, May 7
WHAT WAS PROMISED ☐ Native HubSpot integration — confirmed on May 21 call, connector documentation to be shared at onboarding ☐ SDR onboarding case study from a similar-stage SaaS company — promised May 18, not yet sent · @sarah.ae ☐ Intro to solutions engineer for technical setup — agreed May 14, not yet scheduled · @sarah.ae
OPEN CONCERNS ⚠ ZoomInfo was evaluated during the process — D.K. raised data coverage concerns. Not fully addressed before close. Worth addressing directly in the first CS call: “What were the coverage gaps you saw with ZoomInfo — let’s make sure we’ve mapped those.”
EXPANSION SIGNALS Waverly sales headcount up 34% in last 60 days — 8 open AE and SDR roles currently posted. Current contract covers the existing team. Expansion conversation is natural at 90 days.
COMPETITOR MENTIONED ZoomInfo — evaluated in parallel. Customer chose Lusha on data quality and ease of use. D.K. was the comparison driver.
SUGGESTED FIRST ACTION FOR CS Email S.R. and D.K. within 48 hours to schedule the kickoff call. Lead with the HubSpot integration setup — it was the question that held the deal up longest. Don’t start with a generic welcome email.
Thread data based on live Gmail connector field format. Contacts verified against live Lusha data, May 26, 2026. Names masked to initials.
Why use Lusha in Claude
Three items on the promises checklist are still open when the deal closes — the case study was never sent, the solutions engineer intro was never scheduled, and the HubSpot connector documentation hasn’t been shared. Without this brief, CS discovers each of these on the first call when the customer asks. With the brief, CS knows before the kickoff call and can address every open item in the first 48 hours. The unknown attendee flag is equally important — someone joined a demo without being identified, and that person may be a technical stakeholder who becomes critical during implementation. The AE is tagged and accountable before moving to the next deal.
Data drawn from 300M+ verified contacts under GDPR, CCPA, SOC 2, ISO 27701, ISO 31700, and TRUSTe.
FAQ
Who runs this — the AE or the CS manager?
The AE runs it immediately when the deal is marked closed-won. It takes 3 minutes and removes the need for a manual debrief. If the AE doesn’t run it, the CS manager can run it using the deal information — but the Gmail thread access may be limited if the CS manager wasn’t on the original sales emails.
What if the AE didn't have a Gmail thread — everything was on calls?
The prompt flags it: “No Gmail thread found — AE should forward relevant email history or meeting notes before CS kickoff.” The prompt can’t surface what wasn’t written down. This is also a useful signal for the sales process: deals closed with no written record are harder to hand off cleanly.
What if the customer mentioned multiple competitors?
All competitors mentioned in the Gmail thread are listed in the COMPETITOR MENTIONED section. The CS owner should know about every alternative that was evaluated — renewal conversations often reference the original evaluation.
Why tag the AE after the deal closes?
The AE is accountable for the items on the promises checklist — specifically the case study and the solutions engineer intro in the example. Tagging the AE in the brief means those items don’t silently transfer to CS without the AE knowing. Both parties are visible and accountable in the same Slack post.
How is this different from a standard CRM handoff note?
A CRM handoff note is static — it’s written at one point in time, often summarized from memory. This brief is pulled from the actual Gmail thread, which means it uses the customer’s exact words rather than the AE’s summary. The promises checklist is extracted from specific email commitments, not from what the AE remembers making. The Lusha contact validation is live at close, not from CRM data that may be stale. All three differences matter during the first 90 days of the customer relationship.
Ready to build this?
Get started with Lusha and set up this play in minutes.
