Lead Tracks

Lodgestory CRM › Settings › Lead Tracks

A Track is a pipeline, a list and a calling queue in one object. Set the stages, who works them, when a "did not pick" comes back, and what your dialers are allowed to do — once — and every lead in that Track follows it.

TL;DR

• What it is — the configuration behind Leads. One Track holds its stages, the lead types it accepts, the pool it assigns from, the retry cadence per outcome, the dialer defaults, the first-response SLA and the dial-time compliance gate.
• Who it's for — Account Owners and Admins. A Track is a policy document your telecallers never have to read.
• Top outcome — one place decides what happens after "did not pick", who a new lead belongs to, and whether a dial at 9:40 PM is allowed. Nobody improvises.

At a glance

How to find it

Settings → Lead tracks. The list shows each Track's stage engine, who owns an arriving lead, the pool that works it, and how many leads it holds — which is also what decides whether it can be deleted at all. Open a Track to edit its stages, accepted lead types, assignment, cadence, dialer, SLA and compliance.

Direct URLs:

• https://lodgestory.com/crm/settings/lead-tracks — the Tracks list; a Track's own page is /crm/settings/lead-tracks/{trackId}.
• https://lodgestory.com/crm/settings/lead-types — the lead types and their capture fields.

Partner API: none yet for Tracks, lead types or scripts — configure them in the app. The LEAD and LEAD_ACTIVITY reports are on the partner reports API.

Downstream: creating your first active Track is what makes Leads and Dialer appear in the sidebar. There is no feature flag — the surface exists once a Track does.

What is a Lead Track?

The problem it solves

Outbound calling is not one setting, it's a dozen — and every one of them is a decision somebody makes badly at 4 PM on a Friday if you don't make it in advance. Which stages does this business go through? Who gets a new enquiry: the person on duty, or nobody until they claim it? When somebody's phone is switched off, do we try again in two hours or tomorrow, and how many times before we give up? May we dial at 9:40 PM? May we dial a number on the do-not-call list if a manager says it's fine?

Scatter those across a dozen screens and they drift out of alignment. A Track holds all of them together, so a pipeline arrives complete: stages, ownership, cadence, dialer, SLA and compliance are one object you can copy, retire and reason about.

What you get

• Two stage engines, your choice per Track.
  • Simple — the Track keeps its own stage list. Fast to set up, and stages are all-to-all by design: a telecaller who learns mid-call that a "New" lead is actually a booked site visit says so in one move instead of walking three stages. Terminal stages stay reachable from anywhere and lead back only into open stages (a reopen).
  • Workflow — the Track's stages are the nodes of a Workflow you already drew. It inherits that workflow's visual editor, its legal transitions and its "capture an outcome before closing" rule. Use this when leads and conversations must move through the same named states.
• Stages that carry meaning, not just a name. Every stage is one of four kinds — Open, Won, Lost, Junk. A lead's status follows the kind of stage it enters, which is how stage and status stay separate concepts instead of two lists that disagree. Any stage can also demand a captured outcome before a lead may leave it.
• Accepted lead types. A Track declares which lead types it accepts, so a Rental lead can't wander into a Track whose stages and fields are about site visits. Moving a lead to a Track that doesn't accept its type means re-typing it as part of the move — the move control asks for a type the destination accepts.
• An assignment pool you already built. A Track points at a Ticket Pool — the same object that routes tickets, with the same strategies (take turns, fewest open tickets and leads, random, take turns by capacity) and the same per-hour rosters and timezone. Lead distribution is not a fourth implementation of round-robin.
• Two ownership modes.
  • Pool — a new lead arrives unowned and waits for whoever pulls next or claims it. Best when the team works a shared list.
  • Assign on arrival — the Track's rule chain runs at intake and picks an owner immediately. Best when leads must have a name on them from the first second.
• Assignment rules with a mandatory default. Each rule is when all of these conditions hold, assign to this person or pool — conditions can test the source, the lead type, any captured field, a UTM parameter or the score. An Assign on arrival Track must have a default owner for leads that match no rule; Lodgestory refuses to save one without it. A lead that matches nothing belongs to nobody, and nobody's leads are the ones that never get called.
• A retry cadence per outcome. One rule per outcome — on or off, how long until the next attempt, how many attempts in total, how many per day, how many days to keep trying, and which stage the lead lands in when the cadence is exhausted. The starting vocabulary is the ten "not connected" reasons an Indian telecaller already recognises, so a migrating team's reports keep meaning the same thing.
• Dialer defaults for the whole Track. Dial mode, how the next lead arrives, after-call wrap time, which call script and outcome form to use, which number to present, and whether a non-final outcome must set a follow-up. Lead calls are always recorded.
• Paced dialing. On a Progressive, Power or Predictive Track a supervisor starts a session from the Team wallboard and the server does the dialing — at a pace held under the 3% abandoned-call limit. See Paced dialing sessions.
• A first-response SLA. How many minutes from creation to the first dial, what happens when it's missed (notify, reassign, or both), and an optional stale rescue for leads that sit untouched too long.
• A compliance gate evaluated on every dial. Calling window, do-not-call verdict and the retry caps — checked at dial time, not once when a list was imported, and every answer (allowed, blocked or overridden) is written to an audit trail.
• Duplicate policy per Track. Repeat enquiries are real business, so the default is to create a new lead every time. When they aren't, a Track can reuse the open lead instead, or refuse the duplicate outright.
• Lead scoring, as a table you can read. Pick the attributes that predict a good lead for this Track — budget, locality, source, whatever the type captures — give each a weight, and map values to points out of 10. A lead's score is the weighted combination, and the work queue ranks by it under the manager's priority. Three rules make it behave the way a floor expects: the first matching band wins, so bands read top-to-bottom like the assignment chain; weights are normalised, so adding a fourth attribute doesn't mean re-deriving the other three; and a field the lead simply doesn't have is skipped, not scored zero — a half-filled lead shouldn't rank below one with a genuinely bad answer. When a missing value is the signal, say so: give the attribute an is empty band and it stops being skipped and scores what you told it to. Turning scoring on over an existing Track offers to score the leads already in it, because a queue that sorts by score would otherwise bury every lead you already had.
• A queue order you can reorder. The bands an agent's next-work queue is assembled from — overdue callbacks, due today, SLA at risk, my open leads, the pool — in the priority your floor actually works them.

How it's different

• The pipeline and the calling policy are one object. Most tools put stages in a CRM screen and dial rules in a dialer screen, and let them drift. Here the stage a cadence gives up into is validated against the stages of the same Track that owns the cadence — a Track cannot be saved in a state that contradicts itself.
• Compliance is checked per dial, not per import. The industry default is to scrub a list when a campaign starts, which means a list scrubbed on Monday and dialled on Friday calls people who opted out on Wednesday. Lodgestory checks at the moment of the dial and writes an audit row whatever the answer — which is what turns compliance from a policy page into something you can show an auditor.
• An override is a record, not a loophole. Where a Track allows dialling a do-not-call number with a reason, the reason is mandatory and stored. It is deliberately held outside the analytics surface: an audit trail's value comes from being narrowly read and tamper-evident, not from being in everyone's dashboard.
• Retire, don't delete. A Track and a lead type both have an on/off switch, and Lodgestory refuses to delete either while leads still reference it — it tells you how many and suggests archiving. Archived Tracks and retired types keep their history, and retired types still contribute their columns to the CSV export.
• Field ids are stable across renames. Rename a captured field and every lead keeps its value; the new label shows everywhere, including the export header.

Customer scenarios

• Real estate, two Tracks. Site visits (Simple stages: New → Contacted → Visit booked → Visited → Booked / Lost) with a 15-minute SLA, assign-on-arrival from the day-shift pool, and an aggressive cadence — did-not-pick retried in 2 hours, up to 8 attempts over 10 days. Rentals runs a pool Track with a gentler cadence and no SLA.
• Regulated outbound. An insurer sets the compliance mode to Block, the calling window to 09:00-21:00 in the lead's own timezone, and do-not-call to block outright with no override.
• After-hours web leads. Enquiries land at 2 AM. On an Assign on arrival Track with nobody on the pool's rota, the pool hands each lead to whoever it picked last — the same warm handoff a ticket gets — so the floor finds them owned in the morning rather than sitting in a pool nobody watches. The first-response SLA clock starts at intake, so size it with the night in mind; or run the Track as Pool with a scheduled Pull next lead → Track sweep automation at 9 AM, which distributes the night's leads across the rota by the pool's strategy.
• Two teams, one workflow. A team that already runs conversations through a New → Qualified → Won workflow makes its lead Track a Workflow Track pointing at the same machine, so a lead and its chat are never in two different truths.

How it fits with the rest of Lodgestory CRM

• Leads is the surface this configures. Everything an agent sees — the stage columns, the callbacks, the outcome form, the next lead — comes from their Track.
• Ticket Pools provide the roster and the picking strategy. A pool can route tickets and leads at once: one rotation covers both, and fewest open counts a member's open tickets and open leads together.
• Workflow Lifecycle Stages can be the stage engine. A Workflow Track also inherits that workflow's require a disposition before the final stage rule.
• Calls carries the dial: the number presented, the recording, the transcript and the call card.
• Disposition templates supply the typed outcome form the dialer shows. Every outcome an agent saves is recorded as the lead's disposition (source Lead) — on that form when the Track names one — and linked to the attempt that produced it, so the dispositions report, the disposition.created webhook and a stage's "capture an outcome first" rule all see lead calls. A form retired after the Track was set up is skipped rather than blocking agents.
• Contacts is the directory a lead points at. A lead never duplicates a person; it references one.
• Reports — the LEAD export flattens each lead type's fields into their own columns; LEAD_ACTIVITY is one row per dial.
• Bookings — a visit or meeting booked for a lead is linked to it and runs the Track's booking rules (above). The BOOKING export carries the Lead ID.

Core concepts

How it works

Stages and status

You define stages with a kind. When a lead enters a stage, its status is set from that stage's kind — an Open stage keeps it in play; Won, Lost and Junk are terminal and set the matching status. A won or lost lead's decision time is the moment it entered that terminal stage, which is what the export's Won/Lost At column reports.

A Simple Track's stages are all-to-all: any open stage can reach any other stage, and a terminal stage leads back only into the open ones. A Workflow Track's transitions are exactly the arrows drawn in the workflow, so the board only offers legal moves.

Assignment

On Pool Tracks, a new lead arrives with no owner. It shows a Pool chip in the list, sits on the Unassigned chip, and any agent can claim it — the server settles races, so two agents never end up with the same lead.

On Assign on arrival Tracks, the rule chain runs at intake, in order, and the first rule whose conditions all hold decides the target. A rule can name a person or a pool; a pool then applies its own strategy and rota. If nothing matches, the default assignment takes it — which is why a Track without one won't save.

The retry cadence

Each outcome has its own rule. Three of the ten standard not-connected reasons — invalid number, incoming calls not available, and number not in use — ship with retry off, because retrying them is a waste of a dial. The rest default to a next attempt in 24 hours (2 hours for busy in another call), capped at 6 attempts, 2 per day, over 14 days.

When an agent records an outcome, the matching rule sets the next callback. When its caps are used up, the lead moves to the stage the rule nominates and stops being retried. An explicit callback the agent typed always beats the rule's.

Bookings

A site visit or meeting booked for a lead (Bookings) is linked to that lead and can move it along. Track editor → Bookings sets what happens:

• Which lead a booking belongs to: the lead it was booked from (the lead sheet's Book, or the dialer's Book a visit or meeting); else the lead whose booking link the customer used; else — for a customer booking themselves from your public page — their most recent open lead. A booking never changes lead once linked.
• Rules run only on open leads. A booking on a won or lost lead is still linked and shown in its history.
• A move is attempted, never forced. If the workflow doesn't allow it, or the stage needs an outcome captured first, the move is skipped and the reason is shown in the lead's history. The next action is still set.
• Rescheduling moves the next action with the booking — unless someone changed it by hand since.
• Turn Apply booking rules off to keep the link and the history but change nothing on the lead.
• Create a lead from a public booking (in the same section, saved straight away): when someone with no open lead books themselves on a public booking page, a lead is created in this Track — its assignment and duplicate rules apply, the source is BOOKING — and the booking rules above run on it. Tick booking pages to limit it; none ticked means every public page. Bookings your team makes never create leads. If two Tracks cover the same page, the one switched on first gets the lead. Each booking shows in the intake's delivery log.

Sources

The Sources card lists the Meta Instant Forms that feed this Track — form name, Page, lead type, whether it is syncing and when its last lead arrived — with a link to Meta Lead Ads, where the forms, their destinations and question mappings are managed. Public bookings have their own switch on the Bookings card; imports, the API and automations need nothing on the Track.

The compliance gate

Evaluated on every dial, in the order that fails cheapest first:

1. Calling window — is it inside the allowed hours? The window lives on the Track and is never hard-coded. Lead timezone means the hours are local to the person being called; Organisation means your own clock, with a fallback zone for leads whose timezone is unknown.
2. Do-not-call — the verdict for this number. A Track either blocks outright, or allows an override that requires a written reason.
3. Retry caps — would this dial exceed the cadence's per-day or total caps?

Every outcome — allowed, blocked, or overridden with a reason — appends a row to the compliance audit trail. In Warn mode the agent sees a banner and may proceed; in Block mode the dial is refused.

On the calling hours. The US rule is primary-sourced: 47 CFR 64.1200(c)(1) forbids solicitation before 8 a.m. or after 9 p.m. local time at the called party's location — which is why "lead's timezone" is the default. India's widely-quoted 9 a.m.–9 p.m. telemarketing window could not be verified against TRAI's own gazette text, so Lodgestory ships it as an editable default and does not present it as a guarantee. Confirm your own obligations.

Consent and number class are not enforced yet. Nothing can record a lead's opt-in today, so a Track that required consent would refuse every dial — the switch is hidden, and shown only on a Track that already has it on, so it can be turned off. The number-class check needs the class of the number being dialled from, which no dial reports yet, so that setting is hidden too. TRAI reserves the 140-series for promotional traffic and the 1600-series for service and transactional calls by regulated entities; choose the numbers you dial from accordingly.

The work queue

An agent's next work is assembled in the Track's band order — by default overdue callbacks, then due today, then SLA at risk, then the agent's own open leads, then the pool. Within a band, a due callback dominates, then the manager's intent (priority, then score), then oldest-waiting. Work more than 30 days old stops being pushed at an agent; it stays on the list and the board, because an unbounded queue is an abandoned queue. A callback is the exception — however far ahead it was set, it returns when it falls due.

Paced dialing sessions

Where: Calls → Team (the wallboard) → Paced dialing. Admins only — a session telephones customers on its own.

A session dials one Track for a pool of agents. Its mode is the Track's Dial mode — Progressive, Power or Predictive; a Preview Track has no session, because its agents press Call themselves. To start one, choose:

• The agents in the pool — Power and Predictive need at least two.
• Call from — one or more of the calling account's numbers, rotated. Required: a carrier refuses a call that asserts no number.
• Lines per free agent (Power and Predictive) — Power dials exactly this many per free agent; Predictive treats it as a ceiling and starts at one until it has measured enough.
• If nobody is free when they answer (Power and Predictive) — a spoken message or an uploaded recording. Required: a customer who answers when no agent is free must hear it within two seconds.

A session is created paused and started in the same click; Pause and Resume at will, Stop is permanent.

How it paces:

• Only ready agents count. An agent is ready while their Dialer page is open, their browser phone is connected, and they are not paused, not on a call, and not owing the last call's outcome. Each ready agent gets at most one call at a time, and paced calls are answered by their browser phone automatically.
• Progressive never abandons. It rings the agent first and dials the customer only once the agent has picked up.
• The abandon rate is the governor. An answered call that reaches no agent within two seconds is abandoned and hears the message. The rate is measured over 30 days against answered calls, and the card shows it against the session's limit (3%). Predictive dials one-to-one until 50 calls have been answered; once there is that much to measure, both Power and Predictive drop back to one-to-one on their own whenever the rate reaches the limit.
• Leads are claimed as they are dialled — for the agent in Progressive, and for whoever takes the call in Power and Predictive. A lead that could not be dialled (no number, on the do-not-call list, the call refused) goes back to the pool; a lead the compliance gate blocks is put off until its calling window opens rather than retried every second.
• Every dial is one attempt. The switch reports each call at hangup and the agent's saved outcome lands on that same attempt — a call nobody answered is recorded, and its retry scheduled, without anyone typing.

Features in depth

Embedded tools

A Track can surface up to a handful of embedded web tools — a pricing calculator, an availability checker — either in a side panel or inside the call script. Each embed has a URL template that can interpolate lead values, and an opt-in allowlist of exactly which fields may travel in that URL. Never "all fields": a phone number or a budget leaves the CRM only because somebody chose it. Embed URLs must be HTTPS.

Call scripts

Scripts are their own objects, reusable across Tracks, with up to 200 blocks: say (what to read out), ask (a question whose answer lands on a lead field), branch (route on a condition), objection (a rebuttal keyed to what the customer said), checklist (mandatory disclosures), and embed. An answer option can pre-set the stage, the outcome and the callback the agent is heading for. A script can be validated against a specific Track — its stage ids, its embeds, and the fields of the lead types it accepts — so a script never points at a stage that Track doesn't have. The blocks an agent actually walked are recorded on the attempt and exported in LEAD_ACTIVITY.

Retiring and deleting

Both Tracks and lead types have an active switch. Turning one off takes it out of the pickers while keeping every lead, every attempt and every export column intact. Deleting is refused while anything still references it: a Track with leads tells you how many and suggests archiving; a lead type in use tells you to archive it instead.

Roles & permissions

Limits a user will run into

Errors & FAQ

Frequently asked

Should I use Simple stages or a Workflow?
Simple, unless your leads and your conversations genuinely need to move through the same named states. Simple stages are faster to set up and let an agent jump straight to the truth. Choose Workflow when you already have the machine drawn and want one source of truth for both.

Can one Track hold several lead types?
Yes. List every type it accepts; each lead captures the fields of its own type, and the export gives every type's fields their own columns.

What happens to a lead when its cadence runs out?
It moves to the stage that rule nominates and stops being retried. If the rule names no stage, the lead stays where it is and simply stops being pushed at an agent.

Can an agent dial outside the calling window?
In Warn mode, yes — they see a banner and it's recorded. In Block mode, no. In both cases an audit row is written.

Who can see the reason somebody gave for overriding a do-not-call block?
Admins, through the compliance audit endpoint. It is deliberately kept out of the analytics surface — including out of Kaylee's reach — because an audit trail should be narrowly read.

Does changing a Track's cadence affect leads already in flight?
Yes. The cadence is read when an outcome is recorded, so the next outcome on any lead uses the current rules.

Can I copy a Track?
Not in one click yet. Create the new Track and send the same configuration — it's one object, so it copies cleanly through the API.

Related modules & next steps

• Leads — the surface this configures.
• Ticket Pools — the roster and strategy a Track assigns from.
• Workflow Lifecycle Stages — the stage engine a Workflow Track borrows.
• Calls — the softphone, recordings and the call card behind every dial.
• Contacts — the directory a lead points at.
• Reports — the LEAD and LEAD_ACTIVITY exports.
• Chat routing & queues — the equivalent capacity model for conversations.