Skip to content

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

  1. System Salesforce
  2. Step Alert with context
  3. Step Clock running
  4. System Slack
Also Escalate Reassign

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. 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. 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. 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. 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. 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. 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. 1

    Set up, and see what is actually connected

    Before anything is built, confirm the ground truth.

    Headless skills build-workflow

    Use 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. 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-workflow

    Use 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. 3

    Start the clock and stop it on real contact

    The part most alerting leaves out.

    Headless skills build-workflow

    Targets 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. 4

    Escalate, then reassign

    Because the clock is only useful if something happens when it runs out.

    Headless skills build-workflow tray-patterns

    At 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. 5

    Handle the four things that break it

    Each one has left a hot lead waiting.

    Headless skills tray-gotchas

    Use 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. 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

Microsoft Teams

The same alert and escalation for reps and managers who work in Teams.

Writes

Outreach

Count the first sequence email as first contact, and start the sequence when the rep accepts.

Reads and writes

Workday

Read approved time off, so a lead never waits on someone who is away.

Reads

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.

Last reviewed October 2026.