Proactive follow-up is the primary differentiator for WISMO. The system should not wait for a customer to open another ticket when backend status changes.
The proactive monitor should remain deterministic: deduplicate events, load saved commitments, compare the new status to the last customer update, and decide whether any action is needed. When the change needs interpretation or wording, the monitor calls a specialist agent and the customer communications agent.
Event Decision Flow
Recommended Triggers
| Backend event | Proactive behavior |
|---|
| Supplier ETA moved later by more than threshold | Notify customer, explain the delay, offer allowed options, and save next supplier check. |
| Supplier ETA becomes available after unknown ETA | Notify customer with the new date and confidence caveat. |
| Warehouse pick exceeds SLA | Notify customer before they ask and commit to the next checkpoint. |
| Label created but no first carrier scan after threshold | Notify customer that handoff is being verified and start allowed trace path. |
| Carrier scan resumes after stalled tracking | Notify customer that movement resumed and provide updated ETA if available. |
| Delivery attempt failed | Notify customer with carrier reason and available reattempt, pickup, or address options. |
| Return-to-sender begins | Notify customer and route refund/replacement choices through approval thresholds. |
| Partial shipment created | Notify customer that items are shipping separately and itemize each shipment. |
| Delivered event received for an open WISMO case | Close the loop with delivery confirmation and reopen path if there is a problem. |
| Follow-up due and no backend change | Send a brief checkpoint if Duckie promised it, or escalate before the promise is missed. |
Saved Values
| Saved value | Purpose |
|---|
wismo_case_id | Stable case key. |
order_id and shipment_id | Prevent duplicate updates across related events. |
condition_type | Current routed condition. |
last_backend_status_seen | Webhook idempotency and dedupe key. |
last_customer_update_at | Prevent over-messaging. |
last_status_sent | Avoid repeating the same facts. |
next_follow_up_due_at | Make customer promises auditable. |
follow_up_reason | Explain why the next run should occur. |
customer_action_options | Keep offered options consistent across runs. |
human_owner | Track ownership for escalated cases. |
Messaging Rules
- Do not send duplicate updates for the same backend status.
- Do not send a proactive update if a human support teammate sent a newer public reply with the same facts.
- Update an existing ticket or conversation when one is open.
- Create a proactive outbound conversation only when there is no active support thread and policy allows it.
- If the status is worse than the last update, say what changed and what Duckie is doing next.
- If the status improves, close the loop and reduce the chance of another inbound WISMO ticket.
- If Duckie promised a follow-up and there is no new backend update, send a brief checkpoint or escalate before the promised time is missed.
Proactive Update Template
Use this structure for customer-facing updates:
- What changed since the last update
- What Duckie knows from the order, warehouse, supplier, or carrier systems
- What Duckie is doing next
- Any customer options, if policy allows them
- When the customer will hear back again
Do not use proactive updates as generic marketing or reassurance copy. The update should contain a real status change, a promised checkpoint, or a useful action path.
Test Cases
Before enabling live proactive messages, replay cases for:
- Duplicate carrier webhooks
- Supplier ETA moving later, then earlier
- Human reply after Duckie saved a follow-up
- Label created without pickup scan
- Partial shipment with one delivered item and one pending item
- Delivered-not-received case that should escalate
- Follow-up due with no backend change
Next Pages
After proactive follow-up:
- Add escalation and resolution.
- Use rollout plan to expand event coverage safely.
