What is lead delivery software?

Lead delivery software records each attempt to forward one Lead to one Destination, such as a CRM, webhook, dialer, or email recipient. Useful proof includes the target, attempt time, transport result, response code or provider identifier, retry history, and final action. A generic sent flag is insufficient because acceptance by a transport does not prove that a downstream system processed the Lead or that a person followed up.

The correct success boundary depends on the Destination contract. Treat accepted, confirmed, retryable, and terminal outcomes as different facts.

Outcome Minimum meaning Evidence to retain Next action
Pending The attempt is queued or in progress. No transport result exists yet. Lead, Destination, Connector, queued time, attempt identifier. Monitor age and worker health. Do not count success.
Accepted The receiving transport accepted the request or message under its published contract. Response code, provider request or message ID, completed time. Count Connector acceptance only. Await confirmation if the workflow needs it.
Confirmed downstream A separate callback, status lookup, or object query confirms the intended downstream effect. Destination object ID, confirmation source, confirmed time. Close the technical handoff. Keep sales follow-up separate.
Retryable failure The result is temporary or indeterminate, and the contract permits another attempt. Safe error category, response code, retry count, next attempt time. Retry with the same idempotency boundary and bounded backoff.
Terminal failure The request cannot succeed without changed data, credentials, permissions, or configuration. Safe reason, exhausted policy, owner, remediation state. Stop automatic retries and move the Lead to operator review.
Important: This table is a transport-agnostic operating model, not a universal HTTP rule or a Lucidity status enum. Every Connector must define which response proves acceptance and whether later confirmation is available.

Why is “sent” not enough?

A single boolean erases the point where the handoff stopped. A worker can serialize a Lead successfully but fail before opening a connection. A webhook can accept a request for later processing. An email provider can accept a message that never reaches the inbox. A CRM can create a record but reject a related task or owner assignment.

Keep the states separate so operators can answer five different questions: Was the attempt queued? Did a Connector transmit it? What did the transport acknowledge? Was a downstream object confirmed? What needs review now?

LeadAngel's current Visual Lead Flow documentation shows why route evidence and upload status belong together: the product exposes the actual route, assignment blocks, and pending, error, or completed upload state. That is vendor-specific routing evidence, but the audit principle applies across Destinations.

What does a transport acknowledgment prove?

It proves only what the receiving protocol and endpoint promise. The most common mistake is promoting transport acceptance into business completion.

Transport result What it can prove What it does not prove Stronger evidence
HTTP 200, 201, or 204 The endpoint reports success according to that method and API contract. That every asynchronous workflow, CRM rule, or human follow-up completed. Returned object ID, status query, or signed completion callback.
HTTP 202 Accepted The request was accepted for processing. Completion. RFC 9110 says processing may not have finished or even occur. Status resource, callback, or later object lookup.
SMTP 250 after message data The receiving SMTP server accepted responsibility for delivery. Inbox placement, message read, or sales follow-up. Provider event, bounce record, and the recipient system's own outcome.
CRM API object ID The named API reports that a record was created or updated. Correct ownership, automation completion, or downstream revenue. Read-after-write query and separate CRM workflow events.
Network timeout No definitive result. The receiver might have processed the request. Failure. Retrying with a new identity can duplicate the downstream effect. Idempotent replay or reconciliation by a stable external key.

The IETF's HTTP 202 definition is intentionally noncommittal: acceptance does not mean processing completed. Likewise, SMTP's core specification distinguishes a server accepting responsibility for a message from later delivery. Design the status vocabulary around those protocol boundaries.

How should idempotency protect retries?

Bind one stable idempotency key to one intended Lead and Destination operation. Reuse that key only when retrying the same operation with the same material payload. Store the key's scope, the first accepted result, and any provider replay indicator. Never reuse one key for another Lead, another Destination, or changed parameters.

A timeout is the clearest reason. The sender does not know whether the receiver committed the request before the connection disappeared. If the receiving API supports idempotency, the same key lets the sender reconcile the uncertainty without intentionally creating a second object. Stripe's official idempotent request guide documents this exact pattern for safely repeating object mutations after connection errors. It is an API-specific implementation example, not proof that every webhook or CRM honors the header.

Sender-side key

Derive or generate a stable operation key and bind it to one Lead, Destination, Connector, and payload version.

Receiver support

Confirm the exact header, retention window, replay behavior, and parameter-match rules in the receiving API documentation.

Concurrent protection

Coalesce overlapping attempts so two workers cannot deliver the same operation at the same time.

Reconciliation path

When the result stays indeterminate, query by the external key or send the Lead to review instead of changing the key blindly.

Which failures should retry?

Retry policy belongs to the Connector contract, not to one global list of status codes. Connection resets, timeouts, rate limits, and temporary server unavailability are common retry candidates. Authentication, permission, schema, or validation failures normally need configuration or data changes first. Some server errors are indeterminate because a side effect may already exist.

Use exponential backoff with jitter, cap the attempt count, and honor a published delay. RFC 9110 defines Retry-After as the server's requested wait before a follow-up, including with 503 Service Unavailable. Preserve each attempt rather than overwriting the first failure with the final success.

What happens after retries are exhausted?

Stop the automatic loop and create an explicit review state. The review record should identify the Lead, Destination, Connector, last safe error category, first and last attempt times, attempt count, and required owner action. It should support a controlled replay after the underlying problem is fixed.

A dead-letter queue is one infrastructure pattern for this boundary. Amazon SQS documents dead-letter queues as a way to isolate messages that were not processed successfully for diagnosis and later redrive. A buyer does not need Amazon SQS specifically, but should require an equivalent terminal holding area, alarm, retention policy, and replay audit.

Which failure details are safe to retain?

Store enough to diagnose the boundary without turning logs into another copy of every Lead. Prefer internal identifiers and normalized categories over raw payloads.

Retain Purpose Avoid by default
Delivery ID, Lead ID, Destination ID Join the attempt to first-party records without copying contact fields. Full names, email addresses, phone numbers, or form bodies in logs.
Connector, attempt time, duration, response code Locate transport and latency failures. Authorization headers, cookies, tokens, or signed URLs.
Provider request ID or external object ID Support reconciliation with the Destination. Whole provider responses when an identifier is sufficient.
Normalized error category and safe summary Group failures and route operator action. Stack traces or error bodies that may echo credentials or Lead data.
Idempotency scope and retry count Explain why the attempt replayed or stopped. Secret values used to authenticate the request.

How should lead delivery status be reported?

Report attempt-level and Lead-level metrics separately. Delivery acceptance rate uses accepted Connector attempts divided by all completed attempts. First-attempt acceptance rate uses only the first attempt for each intended handoff. Recovery rate uses handoffs accepted after at least one earlier failure divided by handoffs that entered retry. Terminal failure rate uses exhausted handoffs divided by all intended handoffs.

Name the denominator beside every percentage. One Lead can have several Delivery attempts, so a successful retry can improve the Lead-level outcome while the original failed attempt remains part of reliability reporting.

Keep marketing measurement separate. GA4 can add traffic and campaign context, but it is not the first-party record that a specific Lead reached a Destination. The lead source attribution guide explains that boundary, while the lead distribution software guide separates target selection from Delivery proof.

Lead delivery software acceptance checklist

  1. Define the object: one intended operation must name the Lead, Destination, Connector, and payload version.
  2. Define success per Connector: document which response proves acceptance and whether later confirmation exists.
  3. Record every attempt: keep queued, attempted, completed, response, and retry times without erasing earlier outcomes.
  4. Bind idempotency tightly: one stable key must not cross Leads, Destinations, or changed operations.
  5. Classify indeterminate results: a timeout is not automatically a clean failure.
  6. Retry selectively: use Connector-specific policy, bounded backoff, jitter, and server guidance.
  7. Stop terminal loops: move exhausted or configuration failures to owned operator review.
  8. Sanitize evidence: retain identifiers and categories, not tokens, personal data, or raw webhook bodies.
  9. Reconcile downstream: store returned object IDs and query or callback evidence when business processing must be confirmed.
  10. Measure with explicit denominators: separate attempts, intended handoffs, accepted handoffs, and downstream confirmations.

How does Lucidity record Lead Delivery?

In Lucidity, a Delivery is one attempt to forward one Lead to one Destination through its Connector. Current Delivery status is pending, succeeded, or failed. The attempt retains its Destination, timing, status, and response code when available. Lucidity's routing overview describes the public capture-to-Destination workflow.

Lucidity's forwarding job uses a stable job identity across retries. A previously successful operation is not sent again for that same idempotency scope, and supported Connectors receive a derived idempotency key. The lead-priority forwarding job allows up to three retries. A succeeded Delivery means the Connector reported success under its contract. It does not claim that a CRM finished every later workflow, that an email reached the inbox, or that a person followed up.

Lead Validation gates automatic Delivery, and a reliable routing workflow keeps the selected Destination explicit. Lucidity Leads and Deliveries are first-party operational facts. GA4 remains traffic context and may lag or change independently.

Inspect one Delivery chain of custody

Bring one Lead and one Destination. See the attempt status, Connector evidence, and retry boundary Lucidity records for that handoff.

Request a Lead Delivery walkthrough