How to connect WhatsApp template delivery metrics with support handoffs

Connect WhatsApp template delivery metrics to support outcomes by joining verified message events to attributable replies, accepted ownership and acknowledged handoffs—not by treating a successful send as a successful conversation. Keep transport reporting separate from support reporting, then connect them through stable references and declared measurement windows.

This guide is for teams operating outbound template messages whose replies may be handled in Intercom and escalated through Slack. It describes data and behaviour to verify, not a ready-made integration. It does not claim that Jely supplies template-event access, campaign analytics, native Intercom integration or automatic write-back, or that Jely is affiliated with WhatsApp.

Keep two lifecycles, not one success flag

The transport lifecycle describes what the sending system can establish: attempted, accepted/sent, delivered, read or failed. Map each source definition explicitly; acceptance by a service may mean only that it queued a request. Read information may be unavailable. Use unknown when no usable outcome can be established, and never invent a state the source does not expose.

The support lifecycle describes the work: reply received, unassigned, accepted by owner, escalated, handoff accepted, answered, resolved and reopened. These are proposed reporting states to map to the actual helpdesk configuration, not product promises. Assignment and acceptance are separate events. A named assignee who has not accepted responsibility is not yet accepted ownership.

An escalation does not remove the original support owner. A specialist can accept internal work while that owner remains accountable for the customer response. Answered is not necessarily resolved, and a new reply can reopen completed work. Retain the transitions, not just the latest label.

For the underlying channel responsibilities, use the existing WhatsApp, Intercom and Slack support-workflow guide. The additional task here is to measure the connection between sending and accountable support.

Build a joined model around messages, replies and work

Use separate linked records rather than one spreadsheet row that changes whenever a callback arrives. One batch contains many logical messages; one message can have several physical attempts and status events. A reply can relate to a conversation without having a proven originating send. Keep those relationships distinct.

A support episode is a defined unit of actionable work, not every inbound message. Several messages can belong to one episode; one Intercom conversation can contain a later reopened episode. Record episode boundaries consistently. Link conversations and handoffs through stable references rather than assuming their counts are interchangeable.

Keep identifiers access-controlled and minimise copied content. A report usually needs a template version and authorised source link, not the full customer history in Slack. If a required field cannot be exported or verified, record the limitation and use a controlled manual process or narrow the report.

Attribute replies without claiming causation

Phone-number matching helps locate a contact; it does not prove which send prompted a reply. Numbers may be shared, and a recipient may have received a reminder, announcement and follow-up before asking an unrelated question.

Use an explicit reply-to message reference when available and verify that it maps to the intended send. Distinguish directly linked replies from rule-attributed replies, where a documented time-and-context rule selects a candidate without direct evidence. Retain ambiguous when several sends remain plausible and unattributed when none is supportable. These are evidence labels, not statistical confidence scores.

Do not automatically assign an unthreaded reply to the latest template. Keep candidate references and the review reason. Late replies can remain operationally linked but sit outside the declared reply-rate window. When the association changes after review, version the report rather than silently moving a reply between campaigns.

Even direct linkage establishes message association, not incremental marketing impact. A reply is not necessarily positive engagement, reading is not understanding, and neither proves consent or a service outcome. The SaaS support and customer-history article covers preserving earlier template context; this model adds evidence and counting rules.

Define formulas before comparing batches

Declare the batch, send interval, timezone, observation window, event-time cutoff and extraction time. Count only messages actually attempted in the transport denominator; record suppressed or cancelled-before-send items separately. A logical message is one intended send to one recipient. Retries retain that identity but receive separate attempt references; a deliberate new send has a new identity.

For a fixed cohort of N attempted logical messages, use mutually exclusive current outcome buckets at cutoff: D has verified delivery, including read; F has confirmed failure with no delivered attempt and no outstanding retry; P is known pending or accepted-only; U has no usable outcome evidence. Reconcile so N = D + F + P + U. Mark contradictory evidence for review; do not silently choose whichever callback arrived last.

Use N/A for a zero denominator. If delivery data is unavailable, do not substitute accepted sends into R / D; publish a separately named replies-per-attempted-message measure and disclose the gap. Count replies associated with unknown delivery separately rather than inventing delivery evidence.

Unique-recipient reporting needs its own deduplicated numerator and denominator. A recipient receiving three messages is three logical sends but one recipient. Do not divide delivered messages by unique contacts. Publish directly linked and rule-attributed results separately where their interpretation differs.

Use elapsed time unless explicitly reporting staffed-hours time; show the calendar used for the latter. Completed ownership times exclude still-unowned episodes, so always show their count and waiting age to avoid making a queue look fast by omitting its worst cases.

Reconcile events before trusting the totals

• Duplicate or repeated callbacks: retain raw evidence, deduplicate using source event IDs or a tested composite key, and apply each transition once. A repeated delivery receipt must not increase D.
• Delayed and out-of-order events: retain event time and ingestion time. Apply validated source semantics; an earlier accepted event arriving after delivery must not downgrade the outcome.
• Missing events: check source completeness and permitted reconciliation methods. Distinguish known pending from unknown; silence proves neither failure nor success.
• Retries and uncertain sends: link each attempt to its logical message and provider reference. Before retrying a timeout, investigate whether the original send succeeded. Flag duplicate customer-visible delivery separately.
• Reopened cases: preserve prior resolution and reopening timestamps. Reopened work is open at cutoff, not both a current resolved item and a current open item.
• Reporting cutoffs: freeze the cohort and count qualifying event times up to cutoff using evidence ingested by extraction. Label incomplete reply windows provisional. Publish versioned restatements when late-arriving evidence changes earlier results.

A reply received after W is not backdated into the window, even if it clearly references the send. A reply received within W but ingested later may justify a restatement. Keep support running for both: reporting exclusions are not permission to ignore people.

Fictional worked example: delivery is only one part of the result

This is a fictional measurement exercise, not a Jely customer result or benchmark. Batch B-026 sends one template version at 09:00 UTC on 26 October 2026. Its 1,000 logical messages reach 900 unique recipients. There are 1,120 physical attempts, including 120 retries of those same messages. Suppressed contacts were excluded before attempting the batch.

The reply window is 24 hours after send: from 26 October at 09:00 UTC, inclusive, to 27 October at 09:00 UTC, exclusive. Both the status cutoff and extraction time are 27 October at 09:00 UTC. The snapshot uses only evidence ingested by then; later evidence requires a labelled revision.

• Transport: 800 logical messages delivered, including 300 with a read event; 100 confirmed failed; 60 accepted/pending; 40 unknown. The buckets total 1,000. Delivery is 80%, failure 10%, pending 6% and unknown 4%. Read events are a subset of the 800, not another outcome bucket.
• Attributed replies: 200 distinct delivered messages each receive a directly linked actionable reply within W. These create 200 support episodes in this simplified example. Windowed reply rate is 200 / 800 = 25%; replies per attempted logical message is a separately labelled 200 / 1,000 = 20%.
• Other replies: 15 additional actionable episodes are ambiguous or unattributed. They remain in the operational queue and outside the 200-episode campaign-associated cohort, so total incoming actionable workload is 215 episodes.
• Ownership: 170 of the 200 attributed episodes have accepted ownership; 30 do not. Unowned-reply rate is 30 / 200 = 15%, and acceptance coverage is 85%. Among the 170 accepted episodes, the fictional observed median is 12 minutes and the 90th percentile is 45 minutes; the 30 open waiting ages must be reported separately.
• Handoffs: 50 specialist handoffs are requested across 50 of the owned episodes; 40 are acknowledged. Accepted-handoff rate is 40 / 50 = 80%, leaving 10 requests needing follow-up.
• Current outcomes: 140 attributed episodes are resolved and 60 are open: 30 unowned, 10 awaiting handoff acceptance, 10 reopened and 10 other owned/waiting items. The unresolved proportion is 60 / 200 = 30%. Of 150 episodes ever resolved, 10 reopened, leaving 140 currently resolved.

No unique-recipient delivery or reply rate can be calculated from these aggregates alone. The reviewer also needs the 15 unattributed episodes’ ownership and outcomes; excluding them from campaign attribution must not exclude them from staffing decisions. An 80% delivery rate does not cancel 60 open attributed episodes, 40 unknown outcomes or any unreviewed delivery failures.

Turn the measurements into owned actions

Delivery failure: assign review, check the cause and preferences, and choose a safe retry or approved fallback. Reply without accepted ownership: surface it in the monitored Intercom queue where used, with an accountable reviewer and deadline—not merely a dashboard warning.

Specialist help: create a linked Slack escalation with the conversation reference, requested action and receiving owner. Keep it open until acknowledged; internal discussion is not an authorised customer reply. If integration is unavailable, use a documented manual handoff rather than implying automatic synchronisation.

Rising backlog: review sending pace, audience relevance, reply categories and staffed capacity before expanding another batch. Reduce or pause further sending where appropriate; do not hide unowned work behind good delivery numbers. The event-platform notification guide covers relevance and volume controls in a practical vertical setting.

Implementation checklist and acceptance test

1. Verify sources: document exposed template, message, delivery, reply, Intercom and Slack fields. Record unsupported capabilities, access limits and manual alternatives.
2. Freeze definitions: agree logical-message and episode boundaries, attribution classes, denominators, timezone, W, cutoff, extraction policy and named metric owners.
3. Protect the records: approve role-based access, minimal content, source links and retention. Keep internal notes separate from external replies.
4. Pilot one batch: trace sends through delivery, replies, accepted ownership, specialist work and current outcomes. Compare derived records with authorised source evidence.
5. Reconcile and act: review missing links, unowned replies, overdue handoffs and unknown transport states before expanding.

Use a controlled acceptance test with known expected results: send a test message, repeat its delivery event and deliver an older accepted event afterwards. D must remain one. Fail a separate attempt, retry it successfully and confirm one delivered logical message plus two physical attempts, not an extra failed logical message.

Next, send two templates to one test contact and submit an unthreaded reply: it must remain ambiguous unless verified evidence resolves the link. Test an explicitly linked reply, a bot acknowledgement without owner acceptance, a Slack handoff without acknowledgement, and a resolved case that reopens. The bot must not stop the ownership clock; the unaccepted handoff and reopened work must remain outstanding.

Finally test a reply outside W, an in-window reply ingested after extraction, a zero denominator and a missing event feed. Expect window exclusion, versioned restatement, N/A and disclosed unknown coverage respectively. Assign someone to every unresolved exception. Passing means the numbers reconcile and people can act on the gaps—not simply that notifications appeared in three tools.

Frequently asked questions

Measure the handoff, not just the send

Jely’s stated focus on visible WhatsApp coordination, routing and team handoffs may support parts of the operating workflow, subject to verified configuration. This reporting model remains a separate requirement to validate. Keep attribution honest, unknowns visible and support ownership explicit; a campaign is not operationally complete while the replies it generated have no accountable next action.