Separate audience membership, consent, and channel eligibility
A common first implementation queries a CRM segment and immediately submits every associated LINE user ID. It works for a pilot, but it becomes difficult to control once customer records change during a run, people appear in overlapping segments, or their LINE relationship is no longer usable. Treat business eligibility, consent, and channel reachability as separate decisions. One generic eligible flag cannot explain which rule passed or why a recipient was excluded.
Create an immutable audience snapshot for every campaign. Store the segment rule version, generation time, source system, qualifying reason, and exclusion reason. Sending workers should consume the snapshot instead of repeatedly evaluating a live CRM query. If current status must be checked immediately before sending, record that second decision as part of the campaign history. This preserves the evidence needed to reconstruct a send even after customer attributes or business rules have changed.
- Business eligibility: contract state, product, region, lifecycle stage, transaction status, or support workflow.
- Consent eligibility: notification purpose, capture source, notice version, effective time, and any later withdrawal.
- Channel eligibility: completed account linking, a valid LINE identifier, and no known condition preventing contact.
- Suppression rules: opt-outs, test accounts, duplicate identities, internal blocks, and campaign cooldowns.
Model consent as an event history, not a profile checkbox
A mutable consent checkbox says very little during an audit. A stronger design records events: who acted, when they acted, which interface or process captured the choice, what notification purpose it covered, and which notice version was presented. A withdrawal becomes a new event rather than deletion of the original record. Current eligibility is derived from the ordered history and the applicable policy. This also supports re-enrollment, account relinking, and withdrawal from one notification category without disabling every message.
Adding a LINE Official Account, linking an account, and agreeing to promotional or operational notifications are not automatically equivalent. Service incidents, transaction updates, support reminders, and promotions may require distinct purpose categories. When evidence is incomplete, use an unknown or suppressed state instead of interpreting missing data as permission. Centralize this decision in one eligibility service so that the CRM, scheduler, and administration console do not evolve conflicting consent logic.
- Do not overwrite silently: corrections should retain the actor, timestamp, reason, and previous evidence.
- Suppression takes precedence: renewed segment membership must not bypass an active withdrawal.
- Keep purposes specific: avoid one broad consent field covering service, transactional, and promotional messages.
- Limit retained data: keep what operations and auditability require, with appropriately restricted access.
Use idempotent jobs and an explicit sending state machine
Scheduler retries, worker timeouts, and network failures can all create duplicate messages. Give every intended notification a stable idempotency key derived from the campaign, recipient, message version, and scheduled batch. Before calling the platform, a worker should atomically claim that key and create an attempt record. If the API outcome is ambiguous, do not immediately classify it as failed and send again; the platform may already have accepted the request. Mark it unknown, reconcile it where possible, and apply a deliberate resend policy.
A practical state model includes queued, suppressed, sending, platform accepted, completed, failed, and unknown. Each transition should carry a timestamp, batch identifier, request correlation data, and normalized error category. Retry transient failures and rate limits with bounded backoff. Stop automatic retries for invalid identifiers, authorization failures, or malformed message content until the underlying problem changes. Divide large audiences into batches sized for platform constraints, observability, and affordable recovery rather than maximizing throughput alone.
- Campaign record: content version, schedule, audience snapshot, and approval state.
- Recipient record: eligibility decision, suppression reason, idempotency key, and latest state.
- Attempt record: submission time, platform request identifier, attempt count, and normalized error.
- Batch record: target count, accepted count, completed count, failed count, and unresolved count.
Report only what the platform can prove
The most damaging reporting error is turning a successful API response into delivered or even read. An accepted request usually proves that the platform received a valid submission; it does not necessarily prove device-level delivery to each recipient. Batch progress and aggregate results may also lack recipient-level confirmation. Keep submitted, accepted, processing completed, failed, interacted, and read as distinct concepts. If the integration has no reliable evidence for a state, do not infer it.
An operations dashboard should reconcile the entire funnel: people selected by the original snapshot, people suppressed by consent or channel rules, recipients actually submitted, completion and failure totals reported by the platform, and any unresolved difference. Clicks and replies belong to separate event streams. They can be associated through campaign parameters or webhook events, but they should not be presented as delivery evidence. Useful alerts cover stalled batches, a growing unknown state, changes in failure categories, and totals that no longer balance across systems.
Before launch, test duplicate scheduler runs, interruption after submission, consent withdrawal during a batch, delayed CRM updates, invalid LINE identifiers, and temporary platform outages. Reliable automation does not mean promising that every message will succeed. It means avoiding duplicate disruption when outcomes are uncertain and giving engineering, customer service, and audit teams the same defensible record. When LINE OA, CRM, ERP, and data platforms all participate, an integration team can help define those state and ownership boundaries as one verifiable workflow.