MARSEN CRM LEAD FOLLOW-UP TEMPLATE

Status: synthetic operating template. No row describes a real person, company,
lead, delivery or customer result. Replace every example value before use.

Purpose
Use the CSV to agree the minimum record, ownership rule, next action and
exception state before connecting a form, CRM or messaging provider.

Core identity
- lead_id identifies the working lead record.
- source_event_id identifies one intake event. A repeated source_event_id must
  not create another record or message.
- duplicate_of records the retained lead when a repeated event is held.

Ownership and state
- owner is the person or queue accountable for the next action.
- stage describes business state; message_status describes delivery state.
  Do not use "sent" for a draft or a provider timeout.
- next_action and due_at make the handoff testable.
- exception_reason explains why the normal path stopped or changed owner.

Example scenarios
1. New unanswered enquiry with a prepared response.
2. Qualification question delivered; waiting for the customer.
3. An overdue promise requiring escalation.
4. Duplicate delivery held without another message.
5. Reassignment to a fallback owner.

Implementation checks
- validate required fields and preserve the original request;
- apply one documented ownership rule and fallback;
- recheck current stage, permission and replies before every delivery;
- record provider confirmation separately from preparation;
- reconcile unknown delivery outcomes before retrying;
- stop obsolete follow-ups after reply, booking, decline or opt-out;
- keep personal details and message content out of analytics events.

The template is platform-neutral. A production implementation requires the
actual CRM fields, provider capabilities, access controls, retention policy,
review rules and exception owners.