A 200 response is not a delivered lead: design an acceptance contract

A form can return HTTP 200, clear every field, display a green confirmation, and still lose the lead. The status code only tells the browser that one HTTP exchange completed. It does not prove that the submission was stored, that a manager received it, or that the CRM created a usable record.

Define acceptance as a business state

We use an explicit acceptance contract. First, the server records the submission with a stable identifier and attribution. Second, it attempts delivery to the configured accountable destinations. Third, it returns a machine-readable state. Accepted means the server record exists and at least one required manager or CRM channel has confirmed receipt. Pending means the data is safe but delivery still needs attention. Failed means the server could not safely retain the request.

{
  "accepted": true,
  "server_recorded": true,
  "manager_notified": true,
  "crm_synced": false,
  "submission_id": "stable-id"
}

Persist before calling external systems

Telegram, email, CRM, and automation webhooks are external dependencies. They time out, rotate credentials, reject payloads, and occasionally return misleading intermediate responses. Persisting first gives operations a recovery point. The record should include the original request, consent and policy version, landing page, campaign parameters, referrer, timestamps, and delivery attempts without storing more personal data than the workflow needs.

Make retries idempotent

Users retry when a page looks slow. Browsers also repeat requests after network interruptions. Derive or issue a stable submission identifier and enforce uniqueness at the storage layer. A repeated request should return the existing state and retry only unfinished delivery steps. It must not create three CRM deals or notify the same manager three times.

Keep pending visible

The browser must clear the form only for an accepted response. For pending or failed states it should preserve the entered data, state what happened in plain language, and offer a safe retry. This is not merely interface polish: it prevents the UI from making a promise the backend has not fulfilled.

Measure the accepted event, not the click

Send generate_lead only after the acceptance contract is satisfied. Form starts, submit clicks, validation errors, pending deliveries, qualified leads, booked calls, and converted opportunities are separate events. Otherwise the dashboard rewards a front-end animation while the real funnel can remain broken.

Release with evidence

1. Submit a clearly marked test lead through the production page.
2. Verify the server-side record and its stable identifier.
3. Verify the actual manager notification or CRM record, not only a mock response.
4. Confirm attribution and consent fields survived the journey.
5. Retry the same identifier and confirm there is no duplicate notification.
6. Record the release, test identifier, destination, and cleanup decision.

A lead is accepted when an accountable system confirms responsibility for it, not when the browser feels optimistic.