Speed to Lead for Sales Teams: Reroute, Pool, Alert

Why does a speed-to-lead policy usually fail without a mechanism behind it?

Most sales managers already know the theory: call fast, or lose the lead. The thirty-second standard is not a secret. What fails is the mechanism. A lead lands in a shared inbox or a CRM view, a notification fires, and whether it gets actioned in the next minute or the next hour depends entirely on whether the right rep happens to be looking at their screen at that moment. A policy written in a sales handbook does not call anyone. Team Mode replaces the handbook with a system that decides, second by second, whose job a lead is right now.

How does a lead actually reach a rep the moment it becomes due?

Every lead in the cadence has a due time for its next attempt. The moment that time arrives, the lead appears in a live Due now queue inside the console, ordered so the most overdue task sits at the top. The same queue is mirrored on the rep's phone through MAJ Leads' installable PWA, with a push notification and a sound, because a brokerage or clinic rep is rarely sitting at a desktop between calls. There is no digest email to open later and no separate app to remember to check. The queue is the same console the rep already works in, installed as an app on the device they are already carrying.

How does the one-tap call work from a rep's own phone?

Tapping a due lead opens the call with a tel: link, so the rep dials from their own number using their own phone's dialler. There is no separate softphone to log into and no delay waiting for a bridge to connect. A click-to-call bridge that keeps the call inside the console is planned once SIP support ships, but the v1 mechanic is deliberately simple: the fastest way to get a rep talking to a lead is to hand them a number and let their phone do what it already does.

What happens right after the call ends?

The rep records what happened with one of four outcome buttons: Qualified, Not interested, No pickup, or Callback at, which opens a time picker for a promised callback. Each outcome moves the lead differently. Qualified and Not interested close the loop and hand the lead on, Qualified toward booking and CRM push, Not interested to a terminal state. No pickup returns the lead to the RNR cadence for its next scheduled attempt. Callback at schedules a specific attempt at the time the lead actually asked for, inside the calling window, rather than forcing it back into the standard sequence and calling at the wrong moment.

How does a lead get assigned to a specific rep in the first place?

Assignment runs on rules the team sets up once, not on whoever happens to grab a lead first. A workspace can run straightforward round robin across the team, or rules that route by source, area, or whatever split makes sense for the business, a brokerage routing by community, a clinic routing by treatment type. Either way, a lead has exactly one owner at any given moment, which is what makes every other mechanic in Team Mode possible. Reroute, pooling and escalation all depend on there being a single, unambiguous answer to "whose task is this right now," and the assignment rules are what keep that answer unambiguous.

What do available, away and offline mean, and why does auto-away trigger at 15 minutes?

Every rep carries a status: available, away, or offline. A rep can set away manually for a lunch break or a scheduled viewing, but most of the time reps simply forget to flip the switch, which is why the system also moves a rep to away automatically after 15 minutes of idle time. Fifteen minutes is short enough that a genuinely busy rep is caught quickly, before too many due leads pile up against them, but long enough that a rep who steps away for a two-minute conversation at the front desk is not marked away and rerouted away from every task they were about to work.

What happens to a rep's due tasks the moment they go away?

The instant a rep's status changes to away, whether by their own hand or by the 15-minute idle timer, any task due to them reroutes to the next available rep in the pool immediately. There is no waiting period and no grace window, because the whole point of the reroute is to protect the calling window on the lead's side, not the rep's. The only exception is a lead a workspace has explicitly marked sticky_assignment, which stays with its original rep even while they are away, for cases where continuity with a specific rep matters more than raw speed, a repeat client or an active negotiation, for example.

Why does an unclaimed task go to the pool at 10 minutes and trigger an admin alert at 20?

Reroute on away covers the case where the system knows a rep cannot act. The 10 and 20-minute thresholds cover the harder case: a rep shows as available but simply has not touched the task. At 10 minutes, an untouched task returns to the shared pool, so any free rep, not just the original owner, can pick it up rather than the lead sitting idle behind one person's attention. At 20 minutes, if it is still untouched, an admin gets an alert and the lead is flagged Unattended on the dashboard. Ten and 20 are set where they are because the goal is layered protection: a short window that keeps a single lead from stalling behind one busy rep, and a longer window that makes a genuine breakdown visible to someone who can intervene, rather than letting it hide inside one rep's queue indefinitely.

Why do these particular timers matter more than a generic reminder or a daily report?

The research behind the thirty-second standard is specific about decay, not just delay: contact attempted within five minutes of a lead arriving converts dramatically better than contact attempted at thirty minutes, a gap documented in the Harvard Business Review study behind this cluster's pillar post. A daily or even hourly report on missed leads tells a manager about the damage after it has already happened. A 10-minute pool and a 20-minute alert act while the lead is still inside, or barely outside, the window where a call actually has a chance of landing. The mechanism is built around the same decay curve the research describes, not around what is administratively convenient to report on at the end of the day.

Where does a manager actually see all of this happening?

The dashboard carries a running Unattended count alongside leads by source, speed to first attempt, contact percentage and booked percentage across the whole team. It is not a report a manager pulls together at the end of the week, it updates as leads move through the cadence, so an unusually high Unattended count on a Tuesday afternoon is visible on Tuesday afternoon, while there is still time to redistribute work or check whether a rep has gone quiet for a reason that needs following up.

Does Team Mode replace the need for AI Mode, or the other way round?

Neither replaces the other. A team can run Team Mode as the default during working hours and switch on AI Mode to cover after-hours arrivals and overflow when every rep is already on a call. Any lead the AI decides needs a person, a complex question it cannot answer, is routed back into Team Mode as a normal task, going through the same due-now queue, the same reroute and pooling logic, and the same 10 and 20-minute thresholds as any other lead. The routing mechanics described here are the same regardless of whether the lead's first attempt was made by a person or an AI agent.

What does a sales team need configured before this runs on real leads?

Onboarding walks through sources, then team and routing, where assignment rules, sticky-assignment preferences and the rep list are set once. From there the go-live checklist has to reach one hundred percent, the team added, routing rules in place, before the workspace goes live. Every rep installs the same console as a PWA on their own phone rather than downloading a separate app from a store. Compare running this against AI Mode, read more about Team Mode directly, and see current pricing, Team Mode starts from AED 299 per month, on the pricing page. The full mechanics for a sales team sit on the lead management system page.