How RouteDeck works: the life of a lead

Leads reach RouteDeck through a source: an API key your website or vendor posts with, a hosted form link, an email address that accepts lead emails, or a manual entry in the CRM. Every submission carries a reference, the stable id your form gives that person. Two posts with the same reference update one lead; they never create two. That is what makes progressive forms work: the first page creates a partial lead and every later page enriches the same record.

On the way in RouteDeck normalizes what it can (phones, money, provinces, durations, dates) and keeps the raw value you sent beside the cleaned one. A value it cannot read is flagged on the lead, never coerced and never thrown away. Every lead also stores a consent snapshot: the exact wording the person agreed to, when, from which address, and on which page. That is your CASL evidence, and it is on the record before anyone asks.

Each lead type has a completeness rule, built from its required fields under Lead Types and Fields. A submission that satisfies it is complete and goes straight to routing. One that does not is partial: RouteDeck waits for the rest of the fields to arrive under the same reference, for the falloff window set under Falloff and Partials (fifteen minutes by default). A partial that completes inside the window routes as if it had arrived whole. One that does not moves to Falloff, a queue in the CRM where your team can finish the application and send it back into routing.

A complete lead whose phone or email matches another lead from the last thirty days, and that did not arrive under a known reference, is treated as a repeat. Repeat handling is configurable; by default a repeat is held for a human rather than sold twice.

Your Tier Ladder is an ordered list of tiers. Each tier has a rule written in plain language (province is any of Alberta or Saskatchewan, monthly income is at least a number, consent is Yes), a price per lead, and the buyers who receive it. A complete lead walks the ladder from the top; the first tier whose rule matches wins and the walk stops. Tier order is therefore the whole strategy: the tier you want to fill first sits at the top.

Every save of the ladder publishes a new version and keeps the old one. A lead records the version that placed it, forever, so you can always answer why a lead went where it went. A complete lead that matches no tier is not lost: it lands in Catchall, a queue in the CRM your team works and can re-route once something changes.

A placed lead is delivered to the tier's buyer by the delivery methods you set on the buyer: an ADF email (the machine-readable format dealer systems import), a branded HTML email, or a signed webhook post. Every send is a row with a status. Queued means it is about to go. Sent means the provider accepted it. Bounced means the buyer's mailbox refused it. Failed means every attempt failed. Failed sends retry on their own with a growing delay; when a primary method is exhausted, the buyer's fallback method is tried next; when every method is exhausted the lead is redistributed to the next eligible buyer, and a notification tells you.

The lead itself moves through delivering to delivered. A buyer can ask for a return within the return window you set on the buyer, from the reason list you set. Depending on the buyer's approval mode a return is approved by you or automatically; approval credits the buyer's account and marks the lead returned. A returned lead can be re-routed from the CRM.

Money follows the buyer. An order is a block of leads a buyer has agreed to take from one or more tiers, with a quantity; deliveries into that tier fill it, and RouteDeck warns you as it approaches full. Every delivered lead becomes a debit on the buyer's account at the tier's price at the moment of delivery. From the buyer page you create an invoice for the leads not yet invoiced, either numbered and emailed by RouteDeck or recorded as issued by another system, and you record payments against a chosen invoice, order or the account. The Invoices page lists every invoice across every buyer and names any recorded reference number that is missing from your sequence.

Catchall and Falloff are queues in the CRM, beside every other lead. A lead record shows the raw and cleaned fields, the consent snapshot, the full timeline of calls, texts and emails, tasks and follow-ups, and the actions: finish the application, find a buyer, re-route, log a call. Everything a person does is written to an append-only audit log, the same log the routing engine writes to.

• Partial: arrived, does not yet meet the completeness rule, waiting inside the falloff window.
• Complete: meets the completeness rule; walks the ladder.
• Falloff: a partial that missed the window; in the CRM queue for a human to finish.
• Catchall: complete, but no tier matched; in the CRM queue for a human to place.
• Delivering: placed in a tier; sends to the buyer are in progress.
• Delivered: the buyer received it; a debit was booked at the tier price.
• Return pending: the buyer asked for a return and you have not decided yet.
• Returned: the return was approved; the buyer was credited; the lead can be re-routed.
• Duplicate: a repeat of a recent lead that your repeat settings chose not to route.
• Queued, Sent, Bounced, Failed, Confirmed: the status of one delivery attempt row, as described above.
• Testing (source): leads arriving through this source are held as tests: never routed, never billed, removed when you confirm the mapping.