A Lead Handoff Is Not Done When the Owner Field Changes
Decision in one minute. If a sales representative can receive a notification for a record that is still blocked as a duplicate, has no usable contact route, or is not visible to that representative, the marketing-to-sales handoff is not complete. Treat it as a small transaction: validate the record, resolve or quarantine identity conflicts, assign an eligible owner, confirm that owner can open the record, deliver one actionable notification, and record acceptance or a reasoned return. Do not count an owner-field update as an accepted lead. This article gives a state contract, a reproducible replay test, and a measurement plan that a revenue-operations team can adapt without buying a new platform.
The source checklist for passing a B2B lead from marketing to sales covers identity, account fit, the prospect's actual words, owner, next action, and feedback. Its valuable baseline is human-readable context. This guide tackles the less visible operational gap: the record, assignment, access permission, and notification can disagree at the exact moment the handoff happens. A useful checklist alone does not prove that a representative received a reachable, permitted, non-duplicated prospect.
Why this is a distinct problem, not another lead-scoring exercise
A score answers an estimate about priority. A handoff answers whether a particular team can act on a particular record now. Those are separate questions. A high-scoring record can be owned by an absent employee, share an identity with an existing customer, carry a contact restriction, or be invisible to the assigned rep. Conversely, a low-scoring explicit request may need immediate handling. A score cannot resolve a transaction-state conflict, and a prettier dashboard cannot show which step failed unless the underlying events were captured.
The need is visible in an actual Zoho community question: form submissions generated assignment alerts before duplicate approval, leaving multiple representatives notified about a record they could not find. That is one public report, not evidence of its prevalence across companies or platforms. It exposes a general failure mode worth testing. Vendor documentation also warns that behavior varies: the Salesforce standard lead duplicate rule can allow creation with an alert in an interactive path, while a separate Salesforce Web-to-Lead support article says automated submissions matching an alert-style duplicate rule can instead be blocked because the form cannot show the alert for a person to resolve. Neither behavior should be assumed for your configuration. Test the actual ingestion path.
Official guidance gives part of the contract. Salesforce's sales and marketing alignment guide says an SLA should define a lead, a follow-up timeframe, and a feedback mechanism when sales disqualifies it. The Microsoft Dynamics 365 lead-management FAQ describes qualification failures and duplicate warnings, including the possibility that a duplicate check prevents qualification. These sources describe vendor behavior and management practice, not a universal, cross-platform handoff transaction. The state model below is my recommendation, not a vendor feature claim.
This is particularly relevant when the business has more than one intake path: web forms, event imports, inbound email, chatbot requests, partner referrals, and manually entered records. A team can agree on a service-level target and still miss it because the timestamp starts before a record is actually actionable, or because a second intake writes over the first owner. The fix is to define the boundary at which a handoff is eligible, then test it under collisions, retries, permissions, and rep absence.
The baseline: what current guidance covers, and what it leaves open
The source page asks for a concise dossier, a named owner and next action, plus return reasons. Salesforce's alignment guidance likewise argues for agreed lead definitions and closed-loop feedback. Those are sound prerequisites. Platform documentation describes how assignment and duplicate settings work in their own systems. A search result or a vendor tutorial may tell you how to configure a routing rule, but it rarely states what to do when the rule runs before an asynchronous duplicate check, after a form has sent an alert, or while the owner is on leave.
The unresolved reader question is: when exactly may marketing call a lead “handed off,” and what evidence proves it? A workable answer should survive retries, temporary outages, and platform-specific ordering. It should distinguish an attempted handoff from an acknowledged one, and it should not silently convert “unreachable,” “pending identity review,” or “owner has no access” into “sales failed to follow up.”
There are three competing instincts that must be reconciled. First, sales wants fast contact, especially after an explicit request. Second, operations wants to avoid duplicate outreach or a representative acting on the wrong account. Third, privacy and customer experience require respecting the actual contact context rather than treating every content download as permission for immediate sales outreach. The right policy does not simply maximize speed or maximize review. It selects a path by risk and intent, then records why.
Videos and general playbooks tend to show the happy-path configuration: create a rule, assign a user, send a notification. We searched for a relevant official walkthrough but did not rely on one as evidence for event ordering, because a video demonstration of one CRM setup cannot establish that your webhook, queue, and duplicate rule execute in the same order. That is a limitation of this article's source coverage, and it is exactly why the replay test matters.
Define a handoff as a state transition with evidence
Use a compact state machine. RECEIVED means an intake event exists. HELD means the record cannot be acted on yet because identity, contactability, policy, or data integrity is unresolved. READY means the minimum admissibility checks passed. ASSIGNED means an eligible owner was selected. DELIVERED means a notification or work item referencing the correct CRM record was delivered to a channel the owner can use. ACCEPTED means the owner acknowledged ownership or performed a qualifying first action. RETURNED means sales rejected it with a structured reason. EXPIRED means the handoff clock or context went stale and requires re-evaluation.
The names are local conventions, not mandated Salesforce, Microsoft, or Zoho lifecycle labels. Many CRMs have existing lead-status fields; do not overwrite those blindly. Represent this contract in a dedicated event table, activity stream, or custom object if necessary. Mapping states into a single mutable lead-status field can erase the sequence needed to investigate errors.
flowchart LR
A[Received] --> B{Admissible?}
B -->|Identity or policy unresolved| H[Held]
H -->|Resolved with evidence| B
B -->|Yes| R[Ready]
R --> O{Eligible owner?}
O -->|No| Q[Operations queue]
Q --> O
O -->|Yes| S[Assigned]
S --> V{Record visible and alert delivered?}
V -->|No| Q
V -->|Yes| D[Delivered]
D --> C{Accepted or acted?}
C -->|Yes| X[Accepted]
C -->|Reasoned refusal| T[Returned]
C -->|Clock exceeded| E[Expired]
T --> B
E --> BThe most important boundary is between ASSIGNED and DELIVERED. An assignment field can be set while the record is inaccessible, the notification fails, or an earlier duplicate review is still pending. Treating that field as completion inflates handoff counts and hides the queue where actual work stopped. Delivery requires an owner-access check and an alert acknowledgment from the delivery system. Acceptance requires a separate event; a sent email is not acceptance.
Define invariants that must remain true before a state change. For READY, the record has a stable internal ID, an identifiable account or person, a supported contact route, a source and timestamp, current contact preferences, and a documented reason for action. “Supported” does not necessarily mean an email address; a callback request might have only a phone number, while a partner introduction may require the partner to mediate contact. For ASSIGNED, the owner must be active, in the correct territory or segment, and authorized to view the record. For DELIVERED, the work item must link to the exact record version and be generated once per handoff attempt. For ACCEPTED, the acknowledgment must be attributable to the assignee or an explicitly delegated teammate.
Recommendation: store both handoff_id and source_event_id. The first identifies a particular attempt to pass the record; the second identifies the intake event. A returning prospect may generate several legitimate intake events over time, while a retry of the same webhook must not create a second handoff. Do not use email address alone as the handoff key: shared inboxes, aliases, changed addresses, and privacy constraints make it unreliable as an immutable event identity.
The original asset: a small handoff replay contract
The reusable asset here is a platform-neutral replay protocol, with a testable transition table and executable reference checker. It is deliberately smaller than a CRM integration. Run it against synthetic fixtures first; then map each field to your real events. This is a design and validation tool, not an assertion that one vendor exposes all of these events natively.
| Test case | Intake and system state | Expected decision | Evidence needed before completion |
|---|---|---|---|
| Explicit demo request | Contact route verified, no conflict, owner active | Assign and deliver | Request text, record ID, owner-access check, delivery receipt |
| Same person submits twice | Second event has same form transaction or source ID | Idempotent retry, no new alert | Original handoff ID and matched source event |
| Possible account duplicate | Similar identity but conflicting account ownership | Hold for review | Candidate matches, reviewer resolution, new state event |
| Existing customer request | Contact belongs to active customer account | Route to account owner or service queue | Account relationship and routing rule version |
| Owner unavailable | Routing points to absent rep | Queue or approved delegate | Availability snapshot and delegate policy |
| Record permission fails | Owner is assigned but cannot open CRM link | Do not mark delivered | Access test failure and escalation event |
| Alert provider retries | Notification succeeds then webhook repeats | Suppress duplicate alert | Delivery idempotency key and first receipt |
| Consent or preference conflict | Opt-out or purpose mismatch | Hold, do not outreach | Preference source, timestamp, policy decision |
| Sales rejects | Wrong sector or no active project | Return with code | Rejection reason, evidence, next owner |
| Clock expires | No acknowledgement in agreed interval | Escalate, re-evaluate | Start time, deadline policy, escalation receipt |
These are ten synthetic cases, not ten observed production incidents. The table was constructed on 22 October 2026 from the source checklist, the public Zoho question, vendor duplicate-rule documentation, and common asynchronous-system failure patterns. It has no measured failure rate and no statistical sample. Its purpose is to make hidden assumptions testable. Add locally observed cases before using it as a release gate.
Here is an executable, dependency-free Python checker for the essential ordering contract. Save it as handoff_check.py, then run python handoff_check.py. The fixture events contain no real customer data. The program fails if a delivered notification precedes a resolved identity hold, if a delivered record is not visible to its assigned owner, if an accepted lead has no delivery, or if the same handoff sends multiple alerts. It uses simple in-memory ordering for clarity; a production implementation must persist events durably and handle out-of-order delivery.
from collections import defaultdict
EVENTS = [
("H-101", "received", {"source": "form-77"}),
("H-101", "ready", {"policy": "v3"}),
("H-101", "assigned", {"owner": "rep-a", "visible": True}),
("H-101", "delivered", {"receipt": "msg-901"}),
("H-101", "accepted", {"by": "rep-a"}),
("H-102", "received", {"source": "form-78"}),
("H-102", "held", {"reason": "possible-duplicate"}),
("H-102", "resolved", {"reviewer": "ops-1"}),
("H-102", "ready", {"policy": "v3"}),
("H-102", "assigned", {"owner": "rep-b", "visible": True}),
("H-102", "delivered", {"receipt": "msg-902"}),
]
def check(events):
grouped = defaultdict(list)
for handoff_id, kind, data in events:
grouped[handoff_id].append((kind, data))
errors = []
for handoff_id, timeline in grouped.items():
kinds = [kind for kind, _ in timeline]
if kinds.count("received") != 1:
errors.append((handoff_id, "intake identity is not unique"))
if kinds.count("delivered") > 1:
errors.append((handoff_id, "duplicate delivery"))
if "delivered" in kinds:
delivery = kinds.index("delivered")
if "ready" not in kinds[:delivery]:
errors.append((handoff_id, "delivered before ready"))
assignments = [data for kind, data in timeline[:delivery]
if kind == "assigned"]
if not assignments or not assignments[-1].get("visible"):
errors.append((handoff_id, "owner cannot open record"))
if "held" in kinds[:delivery]:
last_hold = max(i for i, kind in enumerate(kinds[:delivery])
if kind == "held")
if "resolved" not in kinds[last_hold:delivery]:
errors.append((handoff_id, "unresolved hold"))
if "accepted" in kinds and ("delivered" not in kinds or
kinds.index("accepted") < kinds.index("delivered")):
errors.append((handoff_id, "accepted before delivery"))
return errors
result = check(EVENTS)
print("PASS" if not result else result)
assert not result
This checker intentionally does not infer permission from a role name, validate contact permission, or calculate whether a deadline is appropriate. Those need real system evidence. As a negative test, change visible to False for H-102; the checker should report that the owner cannot open the record. Then move the resolved event after delivered; it should report an unresolved hold. A passing synthetic fixture is only evidence that the checker catches its encoded conditions, not proof that your production handoff is safe.
Implement the contract without creating a new shadow CRM
Start with an inventory of event producers and consumers. Record every source that can create or update a lead, the service account it uses, the CRM object it touches, and the automation that might send an alert. Include manual imports; they often bypass validation logic. For each path, mark whether duplicate detection is synchronous, asynchronous, or only interactive. This matters because the Salesforce documentation above describes different behavior for a user interface and automated Web-to-Lead. Microsoft documents a separate set of qualification and duplicate flows. Configuration and entry point are part of the evidence; vendor name alone is insufficient.
Next, choose a durable event boundary. If a web form writes to a CRM and then a marketing-automation tool posts an event, do not assume both writes will always succeed. Use a stable event identifier, a deduplication store, and a retry policy. The ideal is a transactional outbox when you control the source database: commit the lead update and an outbound event in one local transaction, then publish the event asynchronously with retry. If you cannot control that database, keep an external reconciliation job that compares accepted form submissions with CRM records and delivery receipts. Mark unresolved gaps instead of pretending that a webhook 200 means the whole handoff worked.
Write down the fields that must travel with each event: internal lead ID, external source event ID, event type, occurred-at and recorded-at timestamps, rule version, prior state, new state, owner ID, relevant reason code, and a non-sensitive evidence reference. Do not stuff conversation transcripts or all form answers into notification payloads. A representative needs a concise task and a link to authorized context. An auditor needs enough data to reconstruct why a state changed. These needs overlap but are not identical. The UK Information Commissioner's Office direct-marketing guidance says organizations should plan data use, collect information fairly, and respect people's preferences and objections. This is a UK regulatory source, not a substitute for assessing a particular prospect's jurisdiction and channel.
Separate eligibility from priority. Eligibility asks whether the record is safe and workable to route. Priority chooses among eligible work. Hard holds include an unresolved duplicate that could trigger two reps, contact preference conflict, record not visible to the proposed owner, or missing route for an explicit reply. Priority may use intent or account fit after eligibility passes. Treating a high score as a way around a hard hold produces exactly the confusing alerts described in the public discussion.
For the owner-selection step, define a deterministic fallback. A rule can nominate an owner, but that owner may be inactive, outside the territory, over capacity, or unable to access the account. The fallback might be an operations queue or an approved delegate. It should not be “assign to whoever was last used” if that decision cannot be explained. The record should retain the nominated owner, the failed check, the fallback owner, and the rule version. That gives the team a way to repair routing rather than repeatedly blaming follow-up behavior.
Only then send the notification. Its payload should show who asked for what, the exact next action, any known uncertainty, a deadline appropriate to intent, and a deep link. Do not claim the prospect agreed to a call if they merely downloaded content. Do not expose a broad customer record in an email channel if the recipient can retrieve it through the CRM. Notifications must be idempotent by handoff ID plus attempt number. A transport retry should not produce a second sales task unless the first delivery failed and the retry is explicitly traceable. The Google SRE chapter on distributed periodic scheduling distinguishes jobs that are safe to repeat from actions, such as sending an email, where a second launch can be harmful; it also explains why tracking execution state matters under partial failure. Applying that reliability principle to CRM alerts is an engineering inference, not a claim that Google's cron service is a CRM.
Finally, require acknowledgment or action. The distinction is operationally important: an alert can be delivered to an inbox, but a rep might be unavailable or not responsible for that segment. Acceptance can be a button, task claim, first logged reply, or a manager assignment, depending on workflow. Record which action counts and which does not. A page view alone is a weak acknowledgment if it can be generated by previewing or an automation. A reasoned RETURNED state should send the record back to the correct queue with a code such as wrong account, unreachable route, duplicate, not an active project, or policy restriction.
A worked example: the invisible duplicate alert
Imagine a prospect who submits a request for a product discussion at 09:00. The form creates intake event F-7. A second submission at 09:02 uses the same email but a different product page, creating F-8. The CRM's interactive duplicate rule is configured to allow-and-alert; however, the automated intake may behave differently, as the Salesforce Web-to-Lead support note explains. Separately, an operations review queue flags the second request as a possible match. At 09:03, a routing rule nominates two different reps and sends two alerts. One rep opens the linked record successfully; the other sees a permission error because the record is still held in review.
This is a hypothetical fixture, not a claim about a live company. The mistake is not necessarily that the form accepted two requests. The second request could be legitimate new intent. The mistake is conflating event identity with person identity and sending a sales alert before the record is in an actionable state. A correct trace preserves F-7 and F-8, associates both with a reviewed contact or account, and creates only the handoff attempts allowed by the policy. If F-8 is a retry of F-7, the idempotency key suppresses a second handoff. If it is a distinct new request, the system may add context to the existing work item or open a new task for the current account owner. The decision depends on evidence, not an email-only deduplication shortcut.
For this fixture, define success at three levels. Data success: both intake events are retained and linked to the proper identity decision. Routing success: only an eligible, available, authorized owner gets the work item. Conversation success: the first contact references the actual request and does not make the prospect repeat what they already said. These are different outcome measures. If your CRM can show an owner but not a delivery receipt, report routing success as unverified, not successful.
In a real audit, sample records from each intake path and from both successful and failed cases. A convenience sample of only won deals is biased: failures may never reach opportunity stage. Do not invent a universal “good handoff rate” threshold. Establish a local baseline, segment by path and intent, then set a service objective the team can staff. Measure both elapsed time from eligibility and elapsed time from original request, because a review hold that lasts days still harms the prospect even if the sales clock starts only after review. The two clocks answer different questions.
Metrics that cannot be gamed by an owner-field update
Use a funnel of distinct states: received, held, ready, assigned, delivered, accepted, first meaningful action, returned, and outcome. The numerator and denominator must be explicit. Delivered / ready measures routing reliability. Accepted / delivered measures owner acknowledgment. First meaningful action within policy / accepted measures follow-through. Returned for missing or wrong information / accepted measures input quality. Segment by intake channel, explicit versus inferred intent, territory, and rule version. Never combine a manually reviewed high-intent demo request with anonymous educational downloads and interpret one average response time as quality. Bain's commercial-excellence diagnostic frames sales capacity, sales operations, accountabilities, and sales/marketing alignment as interconnected capabilities; this supports examining the whole handoff system rather than treating a poor outcome as solely a rep or campaign problem. The specific state metrics here are my proposed operating measures, not numbers reported by Bain.
Track the reason a record is held, not just how many are held. A growing duplicate-review queue may indicate a form integration issue, a legitimate repeat-interest campaign, or changed matching rules. Track the age distribution of holds and the percentage resolved to existing contacts versus new contacts. Do not automatically call every match a duplicate; identity matching is a candidate-generation process, and errors in either direction have costs. When a hold is resolved, record who made the decision and what evidence was used.
The clock policy is a business decision. An explicit request may deserve a short target; a low-intent newsletter signup may not justify sales outreach at all. Salesforce's alignment guide recommends defined follow-up timeframes but does not prescribe one universal number. Define the target by intent, working hours, staffing, and jurisdiction. Report breaches with their causes: intake delay, identity review, owner selection, permission failure, notification failure, or rep response. Otherwise the metric pressures the wrong team and creates incentives to manipulate status fields.
An experiment can test whether the protocol improves outcomes, but do not claim impact from a before-and-after chart alone. Campaign mix, seasonality, and staffing changes can move conversion. If you can safely randomize a non-safety-critical improvement—such as a clearer task summary—compare cohorts with the same eligibility rules and track downstream meetings and complaints, not just clicks on alerts. Never randomize consent compliance, duplicate safeguards, or required access controls away for an experiment. Those are guardrails, not optional treatments.
Where this recommendation can fail or need modification
One counterargument is that additional holds slow response. That is true if every possible match waits for manual review. The response is not to remove the check indiscriminately; it is to triage by confidence and harm. Exact retry IDs can be suppressed automatically. Clear existing-account matches can route to the account owner if policy permits. Ambiguous cross-account identity and contact-preference conflicts need review. Measure both safety and latency. If review becomes the bottleneck, improve its queue and evidence, not the definition of delivery.
Another counterargument is that a CRM already has assignment rules and duplicate management, so a separate event model is redundant. It may be redundant in a simple, single-path setup where the CRM provides durable logs for every relevant transition and there are no external alert systems. Verify that rather than building a second system by default. If the CRM shows only the current owner and mutable lead status, the event model fills an audit gap. The goal is an accountable handoff, not more infrastructure.
Sales teams may also reject explicit acceptance because it looks like extra administrative work. Count an existing meaningful action as acceptance if it is reliably logged; avoid adding a button purely for process theater. But be honest about gaps. If no event shows whether the rep could open the record or saw the alert, the handoff is delivered at best, not proven accepted. Leadership should not equate missing evidence with sales negligence.
The same person can legitimately have several requests, business units, and roles. A global email-based merge can erase intent or transfer a record to the wrong team. The source event and handoff attempt must remain distinguishable even when they point to one contact. Similarly, privacy restrictions vary by place and contact purpose; this article does not offer a legal determination. Use your organization's current consent and retention policy as a hard input to eligibility, and get jurisdiction-specific review when required.
Finally, vendor documentation can change, and the cited behavior may not match a customized instance. The official Salesforce pages explain a standard duplicate rule and one Web-to-Lead support case; Microsoft describes its own qualification path. None proves that a specific customer deployment behaves identically. The replay test should be repeated after a CRM configuration change, form migration, assignment-rule reorder, role change, or notification provider change.
A practical launch sequence
First, agree on one explicit handoff definition and choose one intake path for a pilot. Do not start by rewriting every lifecycle stage. Choose five to ten synthetic fixtures that include a clean request, retry, likely duplicate, existing customer, absent owner, permission failure, failed notification, and reasoned return. The number of fixtures is a design choice, not a statistical sample. Add at least one case learned from a real incident, with personal data removed.
Second, map each required event to an actual system signal. If a field does not exist, decide whether to add it, derive it from a reliable log, or declare that state unverified. Assign an owner for unresolved evidence. Verify the proposed assignee's record access with a test account or impersonation mechanism approved by your administrators; do not assume a role label proves access. Involve sales in reviewing the alert text and return reasons, because the payload is their working interface.
Third, replay the fixtures in a non-production environment. Confirm that each route produces no duplicate alert, no alert for a held record, and an escalation for a record without an eligible owner. Confirm the exact link opens for the assigned user, not just an administrator. Compare the event trace to the expected table above. If the CRM cannot model a hold, use a separate queue or event marker while keeping the original record; do not delete it to hide the conflict.
Fourth, run a limited production observation without changing routing decisions. Log handoff events and compare them with existing behavior for a short, explicitly dated period. Review false holds and missed holds manually. Only then switch the path to the new decision contract. Preserve the ability to revert routing rules without losing intake events. Tell sales what changed and how to flag a false alert or unreachable record. A failure-report path is part of the launch, not a later enhancement.
Fifth, inspect the first days by case type. If clean requests become faster but duplicate holds age, you improved one dimension and worsened another. If delivered alerts rise but first actions do not, look at capacity and notification usability. If returns rise after structured reason codes are introduced, it might reflect better measurement rather than worse lead quality. Interpret the series with denominator, policy version, and rollout date attached.
Failure modes and recovery
A duplicate rule blocks a web form unexpectedly. Reproduce the exact automated entry point, not just an interactive CRM creation. Preserve the user's submitted event, investigate whether the duplicate action differs for non-interactive submissions, and create a safe retry or review path. The Salesforce Web-to-Lead documentation cited above illustrates why an alert-style rule may not behave like an interactive warning.
An alert fires while a record is held. Stop claiming delivery as success. Trace the event ordering between intake, duplicate decision, owner assignment, and notification. If the notifier subscribes to any owner change, make it subscribe only to the authorized READY-to-ASSIGNED transition and verify the hold is resolved before publishing an alert.
Two reps contact one prospect. Preserve both traces and stop further automated outreach while ownership is reconciled. Determine whether the records are duplicate submissions, distinct requests, or two people sharing a contact route. Assign one accountable owner and make the correction visible to both teams. Do not silently merge records until the identity decision is justified.
The owner cannot open the record. Move the handoff to an operations queue with a permission-failure reason. Do not mark it delivered, and do not send a second alert with the same broken link. Fix sharing or route to an authorized owner, then produce a new traceable delivery attempt.
Sales rejects without a reason. Return status alone is not usable feedback. Make a small set of reason codes mandatory, with a short note only when the code cannot explain the case. Audit whether the codes remain actionable rather than becoming a ritual. A missing data field is a different fix from wrong market fit or no active project.
The queue grows while SLA charts look green. Check where the clock starts. If it starts at READY, a long HELD interval can disappear from the sales chart. Publish separate elapsed times from intake to eligibility, eligibility to delivery, and delivery to first action. The prospect experiences the whole wait.
Validation checklist
- Can you identify a source event, a handoff attempt, and the exact CRM record separately?
- Does every intake path—including imports and retries—apply the same eligibility and contact-policy checks?
- Can a possible duplicate be held without losing its original request or sending a premature sales alert?
- Is an assigned owner active, in scope, and able to open the exact record link?
- Is the alert idempotent, concise, actionable, and associated with a delivery receipt?
- Do you distinguish delivered, accepted, first action, returned, and expired states?
- Does a returned lead carry a reason code and a next owner or queue?
- Are clocks and denominators published by state and intent, rather than hidden in one average?
- Have you tested a clean request, retry, duplicate, existing customer, absent owner, permission failure, and notification failure in the real integration path?
- Can you name the date, rule version, and evidence behind every handoff decision without exposing more personal information than necessary?
The practical standard is simple: marketing has not handed off a lead merely because its system changed a field. A handoff is complete only when a valid, authorized owner receives a usable work item and the organization can tell what happened next. The state contract, fixtures, and checker above make that standard falsifiable. They do not promise a search ranking, a universal conversion lift, or a one-size-fits-all response deadline.
Top comments (1)
The point that a changed owner field doesn't mean the lead was accepted is the one most teams miss. We've seen leads sit because the rep could be notified but not open the record. When you replay the test, which failure shows up first for you, duplicates or visibility?