Automation · Revenue operations
How to build speed-to-lead alerts
A demo request is routed in four seconds and called back in four hours, because the alert was an email in a folder nobody reads. This is the design behind alerts that get a lead called, the prompts that build them, and what production adds.
Built with Tray Headless
- System Salesforce
- Step Alert with context
- Step Clock running
- System Slack
The clock starts when the lead arrives, and the escalation runs off that clock rather than off the rep's inbox.
The short answer
What are speed-to-lead alerts?
Speed-to-lead alerts are four parts: an alert that reaches the rep where they already work with enough context to call without research, a clock on every lead that starts when it arrives, an escalation path that fires before the lead goes cold, and a reassignment rule for leads nobody picks up. The part teams leave out is the clock. An alert with no follow-up only tells a rep a lead exists. Without a timer behind it, nobody knows the lead has waited three hours until the prospect has booked a call with someone else.
Stage 8 of 9: Rep alert and escalation. Part of Lead routing, end to end : every stage, the systems it runs on and the guide that builds it.
What matters here
- Send the alert where the rep already works, with the lead, the account and the reason it was routed. A bare link to a CRM record makes them do the research first.
- Start the clock on arrival, not on assignment. The buyer has been waiting since they pressed submit.
- Escalate on a timer. If nobody has touched a hot lead in five minutes, the manager hears about it before the buyer gives up.
- Reassign leads nobody picks up. A lead sitting with a rep who is out sick is worse than a lead in a shared queue.
- Stop the clock on a real first touch, a logged call or a sent email, not on the rep opening the record.
Who this is for
You run sales operations or revenue operations. Routing already assigns leads, but response time still varies from minutes to days depending on who got the lead and what else they were doing. You want every hot lead called fast, and a clear record when one was not.
How it works in practice
What happens between a lead being assigned and the first call.
- 1
The lead is assigned and the clock starts
The arrival time is already on the lead. The alert workflow reads it, the target for this lead type, and who owns it.
- 2
The rep gets one message with everything on it
Name, title, company, size, what they asked for, the account owner if there is one, and buttons to accept or pass. In Slack or Teams, wherever the rep works.
- 3
Only real contact stops the clock
The clock stops on the first logged call, sent email or booked meeting. Opening the record or clicking accept does not count as contact.
- 4
Past the target, it escalates
The rep gets a reminder at half the target, and the manager and the team channel are told at the target, with how long the lead has waited.
- 5
Past the hard limit, it is reassigned
The lead goes to the next available rep in the same pool, the original owner is told why, and the reassignment is stamped on the lead.
- 6
Every lead's time lands in reporting
Arrival, alert, first touch, escalations and reassignments, so response time by rep and by source is one query away.
What speed-to-lead alerts are made of
Most teams have the first part. The other three are what turn an alert into a response.
An alert worth acting on
One message with the lead, the enrichment, the matched account and the reason it was routed, posted where the rep works. Accept and pass buttons write straight back to the CRM.
A clock from arrival
Each lead type has a target, such as five minutes for a demo request and a day for a content download. The clock runs from arrival and stops on real contact.
Escalation on a timer
A reminder to the rep, then the manager, then the team, each at a set point on the clock. Nobody has to watch a queue to know a lead is waiting.
Reassignment as a last step
Past the hard limit, or straight away if the rep is out, the lead moves to the next rep in the pool. The original owner is told, and the reason is stamped on the lead.
The Tray Headless prompts
Paste these into Claude Code or Codex with the Tray Headless plugin installed. Each stage runs on its own. The systems named in them are the worked example rather than a requirement, and every prompt says so.
Once per project, run
/tray-workflows:set-workspace
to pick the workspace these build in. Point it at a sandbox first.
- 1
Set up, and see what is actually connected
Before anything is built, confirm the ground truth.
Headless skills
build-workflowUse build-workflow. The systems in play are Salesforce, Slack, Microsoft Teams, Outreach, Workday and Snowflake, or whatever we run in those seats. Before you plan anything, tell me which are already authenticated in the workspace. I expect Salesforce, Slack and Outreach. Tell me what is missing, and do not stub a connector I have not authenticated.
- 2
Send one alert with everything on it
The message the rep acts on, so it has to be enough on its own.
Headless skills
build-workflowUse build-workflow. Trigger when Lead.OwnerId changes to a user (not a queue) and Status is Marketing Qualified. Post a direct message to the owner in Slack with: name, title, company, employee count, what they asked for (form name and any free text), lead source, the matched account and its owner if different, the routing rule that fired, and how long ago the lead arrived. Add two buttons: Accept and Pass. Accept stamps Accepted__c. Pass sends the lead back to routing with the rep excluded and a reason. Both write to Salesforce.
- 3
Start the clock and stop it on real contact
The part most alerting leaves out.
Headless skills
build-workflowTargets come from a table I can edit, by lead source: demo or contact request: target 5 minutes, hard limit 30 trial signup: target 30 minutes, hard limit 4 hours webinar attended: target 1 day, hard limit 3 days The clock starts at Arrived__c on the lead. It stops at the first Task of type Call or Email logged against the lead, or the first meeting booked, or the first Outreach email sent. Stamp First_Touch__c and the minutes taken. Count business hours only for the rep's region. A form at 23:00 starts its clock at 08:00 local.
- 4
Escalate, then reassign
Because the clock is only useful if something happens when it runs out.
Headless skills
build-workflowtray-patternsAt half the target with no first touch, send the rep a reminder in the same Slack thread. At the target, post to the team channel and tell the rep's manager, with the lead, the owner and the minutes waited. At the hard limit, send the lead back to routing with the owner excluded, stamp Reassigned_Reason__c, and tell the original owner. Never reassign a lead that has an open opportunity on its account.
- 5
Handle the four things that break it
Each one has left a hot lead waiting.
Headless skills
tray-gotchasUse tray-gotchas, then handle these explicitly: The rep is out. Read approved time off from Workday and the Slack status. If they are away, skip the alert and reassign at once. The rep works in Teams, not Slack. Send the same card to Microsoft Teams based on a field on the user record. The same lead is routed twice. Keep one clock per lead, and let a second assignment take over the existing one rather than start fresh. Nobody is available in the pool. Post to the team channel and the sales manager, and keep the lead with the original owner rather than bouncing it.
- 6
Report it, then hand it to ops
The step that tells you whether it worked.
Land every alert, touch, escalation and reassignment in Snowflake. Weekly, report median and 90th percentile time to first touch by lead source, by rep and by hour of day, plus the count of leads that hit the hard limit. Then open the workflow in Tray Build so sales operations can change targets and escalation steps without a coding assistant.
The hour-of-day view is usually where the gap is. Leads that arrive at lunch or after 4pm wait the longest.
What it connects to
Alerts read from the CRM and write to wherever reps spend their day.
Salesforce
Read the lead, its owner, arrival time and logged activity. Write accepted, first touch, escalation and reassignment stamps.
Reads and writes
Slack
Send the rep a message with the lead's details and accept or pass buttons, then reminders and team escalations in the same thread.
Reads and writes
Outreach
Count the first sequence email as first contact, and start the sequence when the rep accepts.
Reads and writes
Snowflake
Keep every alert and every touch with its time, so response by rep, source and hour is a query.
Writes
Same build, other stacks
The design does not change if you run something else in one of these seats. The same prompts build it against Microsoft Dynamics 365, Google BigQuery, Google Chat, SAP SuccessFactors, HubSpot or Databricks.
Connections in this build
Field mapping, templates and common problems for each pairing: Salesforce + Slack, Outreach + Salesforce, Workday REST + Salesforce and Workday REST + Slack.
Named systems are the ones most teams run, not the only ones that work. Each is an authentication in your Tray workspace, referenced by name, so the workflow never holds a credential. Where we have a connector page, the name links to it.
Running it in production
The build gets you alerts. Hot leads arrive at all hours, so the alerts need to run properly.
It runs on the platform, around the clock
Timers and escalations need to fire at 07:59 on a Monday as reliably as at noon. They run on the same engine as routing, with retries and a record of each step.
Governance is built in
Audit trail and access control come from the platform, so every reassignment is attributable and the rule that caused it is on record.
Credentials are held by the platform
The CRM, the messaging tools and the HR system are each an authentication in your workspace, never a token in code.
Sales operations owns the targets
Targets, escalation steps and the reassignment pool open in Tray Build, so changing them is a quick edit by the person who owns them.
Failures are visible
Alert when a message fails to deliver or a lead hits the hard limit with nobody available, so a broken alert is not mistaken for a slow rep.
Questions people ask
How is this different from lead routing?
Routing decides who owns the lead. Speed-to-lead alerts make sure that person acts on it, and move it when they don't. The two run back to back.
Why not just email the rep?
Email alerts sit in a folder with everything else. A message in Slack or Teams with the lead's details and an accept button gets read and acted on in the tool the rep already has open.
What counts as first contact?
A logged call, a sent email or a booked meeting. Opening the record or clicking accept does not count, because the buyer has not heard anything yet.
Does the clock run overnight?
It can run in business hours for the rep's region, so a form at 23:00 starts its clock in the morning. High-value lead types can run around the clock with an on-call pool.
Can sales operations change the targets without engineering?
Yes. Targets, escalation steps and the reassignment pool open in Tray Build, so a change is a visual edit by the person who owns them.
Further reading
Background on the same subject, for the case rather than the build.
Related guides
Revenue operations
How to build lead routing that assigns in seconds
Match the lead to an account first, evaluate rules in a fixed order, catch what they miss, and time it from arrival. The Headless prompts that build it.
Revenue operations
How to build a lead scoring sync
Keep fit and activity scores apart, write one score the CRM trusts, let old activity fade, and route the moment a lead crosses the line. The Headless prompts that build it.
Revenue operations
How to build a sales engagement to CRM sync
Log activity without flooding the timeline, suppress sequences on the accounts you must not touch, and keep one definition of engagement. The prompts that build it.
Revenue operations
How to build a territory and quota sync
Apply a plan on its effective date, keep in-flight deals with their owner, and make coverage visible before anybody signs off. The prompts that build it.
Last reviewed October 2026.