The lead status field is one of the most abused in CRM. Teams add statuses casually, remove them without migration plans, and let reps type free text into "other". Strkr treats lead status as a schema object: a controlled taxonomy, enforced transitions, SLA per status, and an audit trail on every change. The downstream reports stop lying.
Lead-status problems look small (a dropdown field) but drive big reporting failures. The six common breakdowns surface when an ops lead tries to answer "how long do leads sit in SQL?" and gets a different answer every quarter because the field changed shape unofficially.
When a lead-status picklist carries a free-text "other" fallback, reps type into it. Reports lose shape; the ops lead sees 60 unique strings instead of one controlled set. Strkr's lead status is enum-only; new values require an admin change with a published change note.
When the picklist allows any-to-any transitions, the funnel middle disappears. Reps move leads straight to disposition states to clear the queue; the ops lead cannot measure stage dwell. Strkr defines a transition matrix (which statuses can move to which) and enforces it at the API, with override auditable to a named admin.
Without an SLA per status, leads rot in the middle of the funnel. Strkr attaches an SLA (max time in status, max idle time without activity) to each status. A breach fires a Flow: reminder to the owner, escalation to the manager, optional reroute to a different owner.
When a lead's status history is lost (overwrite with no log), the ops lead cannot reconstruct what happened. Strkr logs every status change with timestamp, actor, prior state, new state, and reason code; the audit is on the record and in the warehouse export.
When marketing uses "MQL" to mean one thing and sales uses it to mean another, the handoff produces loss. Strkr publishes a shared taxonomy with definitions (what qualifies for each status, exit criteria, SLA, next action). The definition is the source of truth; the picklist renders from it.
Casual renames break downstream reports and automations. Strkr's status taxonomy carries a stable ID per status (not a label-dependent lookup); renames are display-only. Removing or merging a status requires a documented migration path with the historical records remapped.
Strkr treats each lead status as a structured object with eight attributes. The cards below are the eight attributes that make downstream reports and automations behave.
Each status carries a stable UUID that automations, reports, and the warehouse export reference. The display label is a separate attribute; renaming a status does not break anything downstream. Historical records continue to reference the UUID, so trend lines stay intact.
Each status publishes entry and exit criteria in plain language. Entry criteria set the bar for moving in (what the SDR must have confirmed); exit criteria set what triggers the move out. Reps read the criteria from inside the lead record so the handoff vocabulary stays shared.
The transition matrix is enforced at the API. A move from "new" to "closed-lost" is only allowed if the matrix says so. Admin override is logged. The matrix is editable with change-note discipline.
Each status carries two SLA parameters: max total time in this status and max idle time without a logged activity. Breach of either triggers the escalation Flow. The parameters are per-segment-aware (enterprise SQL has a longer SLA than SMB SQL).
For sensitive transitions (closed-lost, disqualified, long-term-nurture), the API requires a structured reason code from a published list. Free-text notes attach optionally; the structured reason drives reporting and feedback-to-marketing digests.
Permissions attach per-status. A rep might see leads in "nurture" but not edit them; a manager can override an SLA breach; the ops lead can rebalance load across statuses. The permission check is server-side, so client workarounds do not exist.
Each status points at a Flow. The Flow fires on entry (set reminder, draft outreach, pull enrichment refresh), on exit (log outcome, feedback-to-marketing), and on SLA breach (reassign, escalate). The Flow is observable with runs linked to the lead record.
Each status carries a classification tag that groups statuses for reporting. Classification tags survive status renames and merges, so cross-period reports stay consistent even when the taxonomy evolves.
A clean starter taxonomy is more useful than a 15-status fine-grained one. The cards below are the eight statuses most Strkr customers run on, with the entry and exit criteria that make the taxonomy legible to both marketing and sales.
A lead sits in "new" from capture until the first SDR triage touches it. SLA is tight (minutes for inbound, hours for outbound). Exit criteria: SDR touches the record, confirms enrichment, moves to "working" or "disqualified".
An SDR is working the lead through a sequence. SLA is a max of 14 days without a logged activity. Exit criteria: lead replies to a meaningful question (move to "engaged"), gives explicit disinterest (move to "disqualified"), or lapses (move to "nurture").
The lead replied with a meaningful signal (asked a question, requested materials, booked time). SLA is a max of seven days to produce a next step. Exit criteria: meeting booked (move to "SQL"), explicit disinterest (move to "closed-lost"), or stall (move back to "working" or to "nurture").
The lead meets qualification criteria and an AE owns the next step. SLA is a max of three business days to the next AE touch. Exit criteria: discovery call completed (convert to opportunity on the Deals pipeline), fail-to-qualify (move to "nurture" or "closed-lost").
The lead is not ready for an active cycle but is a credible future buyer. Marketing owns the status; a nurture sequence runs with a scheduled re-triage date. Exit criteria: re-triage produces fresh signal (back to "working") or confirms stale (move to "closed-lost" with a reason).
The lead fails the ICP check or the contact information is unverifiable. Structured reason code is required. A weekly feedback digest to marketing surfaces disqualification patterns by source and campaign.
The lead converted to a sold opportunity and the deal closed. This status is terminal for the lead object; the opportunity carries the forward motion. Attribution reports read closed-won leads back to the originating campaign.
The lead did not advance. Structured reason code required (no fit, no budget, no authority, no timing, competitor, no response). Reason codes feed the quarterly campaign retrospective and the ICP review.
A taxonomy without governance drifts within a quarter. The cards below are the governance primitives Strkr applies to the lead-status schema.
Admin changes to the taxonomy require a short change note describing the reason and the impact. The note lands in the workspace change log and in the warehouse export so downstream analysts see when the shape shifted.
When two statuses merge, historical records retain the original UUID with a merged-into pointer. Reports can filter on the new unified status or on the historical lineage, which keeps period-over-period comparisons honest.
Status add, rename, merge, and delete are gated to workspace admins. The permission check is server-side; the UI hides the edit controls from non-admins. Each change logs the actor identity and the before/after state.
A pre-change impact preview lists the Flows, reports, and automations that reference the status being merged or deleted. The admin walks the list before confirming. Dangling references are flagged with a one-click rewire.
When the taxonomy changes (a status merges or splits), a migration runs over historical records with the admin's mapping. The migration is reversible and the before-state is kept for 90 days so a rollback is possible without data loss.
A weekly health Flow reports taxonomy drift (statuses used far outside their expected volume), SLA breach rates per status, and the top three reroute patterns. The ops lead reviews the report and refines the taxonomy or the SLAs accordingly.
A lead-status field is only useful if it produces decisions. The cards below are the five cuts Strkr publishes on the lead-status dashboard by default.
Velocity through each status, by segment and by owner. A rising P75 in "working" flags elongation at the SDR layer; a rising median in "SQL" flags AE capacity. The chart links back to the leads driving the number for the ops review.
The breach rate per status per week is the operating signal for the manager. Repeat offenders surface by SDR; policy breaches by segment surface for the ops lead. The Flow runs the escalation; the report surfaces the pattern.
A Sankey diagram of lead transitions over the period reveals handoff patterns and shortcut moves. The map surfaces unexpected flows (e.g., a growing path from "working" straight to "closed-lost" bypassing "engaged") that signal process erosion.
Reasons by segment and campaign drive the feedback digest to marketing and the quarterly campaign retrospective. Reasons shift over time; the trend surfaces ICP drift and campaign mis-targeting.
The ops lead reads the owner load per status to rebalance queues. Overloaded SDRs are visible before the SLA breaches start; underloaded SDRs surface as capacity for a push.
A composite health score (free-text use, SLA breach rate, transition legality, change-note coverage) rolls up to a single health number per quarter. The score is a diagnostic that keeps the taxonomy from quietly rotting.
The picklist in horizontal CRM is a dropdown. Strkr makes it a governed schema object with transitions, SLAs, and audit.
| Feature | Strkr | Horizontal CRM picklist |
|---|---|---|
| Stable UUID per status | Yes; display label separate | Label-dependent lookups |
| Enforced transition matrix | Server-side; override logged | Any-to-any by default |
| SLA per status with Flow escalation | Max time + idle, with reroute | No native SLA |
| Audit history on every change | Actor, timestamp, reason | Overwrite common |
| Structured reason codes on transitions | Required on sensitive moves | Free-text notes |
| Permission-gated taxonomy edits | Admin-only; server enforced | Loose |
| Automation-impact preview | Pre-change dependency list | Discover-at-breakage |
| Historical record preservation on merge | Merged-into pointer | Breaks reports |
| Classification tags for reporting | Open, qualified, nurture, etc. | Flat list |
| Weekly health report | Drift, breach rate, transitions | Ad hoc |
Three common starting shapes for the taxonomy depending on motion.
An inbound-heavy motion runs the eight-status reference taxonomy with tight SLAs on new (minutes) and working (14 days). Nurture carries a 90-day re-triage. The weekly feedback digest to marketing uses the disqualification reason distribution.
A named-account motion collapses the taxonomy to five statuses (new, engaged, SQL, nurture, closed). The SLA is longer per status because the touch frequency is lower; the structured reason codes on closed are richer because named-account loss is more diagnostic.
A high-touch services firm extends the taxonomy to 12 statuses mapped to engagement phases (needs analysis, scope draft, proposal, approvals, signed). Each status has a Flow that fires document generation and signature-request handoffs through the Documents module.
Define the taxonomy, enforce the transitions, time each step, and leave an audit trail. Your downstream reports stop lying.
Status add, rename, merge, or delete requires a change note from a workspace admin. Each status carries a stable UUID so renames are display-only. Merge or delete surfaces a dependency list (Flows, reports, automations) before confirming so downstream breakage is explicit.
Yes. Strkr enforces a transition matrix at the API. Any-to-any moves are not allowed by default; the admin configures which statuses can move to which. Override by a manager is logged with actor, timestamp, and reason.
Yes. Each status carries two SLAs: max total time in status and max idle time without a logged activity. Breach fires a Flow (reminder, escalation, optional reroute). The SLA is per-segment-aware so enterprise and SMB can carry different thresholds.
Every status change logs actor, timestamp, prior state, new state, and reason code (when the transition requires one). The audit is on the lead record and in the warehouse export; no admin can erase a change entry without a documented data-correction flow.
Rejection reasons are structured on closed-lost and disqualified moves (no fit, no budget, no authority, no timing, competitor, no response, plus workspace additions). A weekly digest to marketing surfaces the distribution by source and campaign so the next campaign iteration knows exactly which cuts leaked.
Yes. The migration tool accepts a mapping from source statuses to Strkr statuses, applies the mapping over historical records, and keeps the pre-migration state recoverable for 90 days. Reports read the historical UUIDs so prior-period comparisons remain intact.
No sales call, no migration consultant, no four-month implementation. Enter your card, get 14 days of the full Pro tier, cancel any time before day 14 with zero charge. Spin up a workspace, import your CSV, and have something useful before lunch.
