> ## Documentation Index > Fetch the complete documentation index at: https://docs.duckie.ai/llms.txt > Use this file to discover all available pages before exploring further. # Rollout Plan > Move the WISMO blueprint from testing to live customer-facing operations Roll out WISMO automation in phases. Start with shadow-mode classification and internal notes, then expand customer-visible replies, proactive updates, specialist agents, and approval-gated write actions as quality stabilizes. ## Phase 1: Observe and Model Goal: create the WISMO data contract and validate routing on historical tickets. Build: * Customer WISMO intake deployment in Testing mode * Order context workflow * Condition routing workflow * Standard status agent * Split shipment agent * Carrier exception agent for simple no-scan and no-movement cases * Initial categories, attributes, and resolution rules Keep disabled: * Customer-visible proactive outbound messages * Replacement, refund, cancellation, and address-change writes * Supplier and warehouse edge cases beyond internal notes Exit criteria: * Historical WISMO tickets map to the expected condition labels * Order lookup works for the selected channel * Internal-note drafts are factual and do not overpromise * Restricted states escalate reliably ## Phase 2: Reactive WISMO on One Channel Goal: answer allowed WISMO requests in one controlled live channel. Build: * Live deployment for a narrow chat or Zendesk WISMO group * Read-only OMS, WMS, carrier, inventory, and support-history tools * Customer communications agent for standard, split-shipment, and simple carrier replies * Saved follow-up commitments Guardrails: * Keep replacement/refund/address/cancellation actions human-owned * Escalate high-value, repeated-contact, fraud/address-hold, and low-confidence cases * Suppress replies when a human teammate has sent a newer update Exit criteria: * CSAT or QA score is stable for covered conditions * First-touch resolution improves for selected WISMO traffic * Escalations contain enough context for fast review * Follow-up commitments are saved correctly ## Phase 3: Proactive Event Handling Goal: update customers before they open another ticket. Build: * OMS, WMS, supplier, and carrier webhook deployments in Testing mode * Proactive follow-up monitor * Duplicate suppression for backend events * Customer-visible proactive updates for low-risk events Start with: * Partial shipment created * Carrier tracking resumed * Delivery attempt failed * Label created with no first scan after threshold * Follow-up due with no backend change Exit criteria: * Duplicate updates are suppressed * Existing tickets are updated instead of creating unnecessary new conversations * Proactive updates contain real status changes or promised checkpoints * Missed follow-ups are visible in analytics ## Phase 4: Exception Agents and Slack Review Goal: handle more ambiguous WISMO conditions while keeping risky decisions gated. Build: * Supplier backorder agent * Warehouse investigation agent * Delivered-not-received agent * Resolution eligibility workflow * Slack escalation agent and review channels * Draft replacement, refund, cancellation, and address-change actions Guardrails: * High-impact actions require approval * Alternate component recommendations require approved compatibility data or human review * Fraud, payment, and address-hold cases always use restricted language and escalation paths Exit criteria: * Slack reviewers can approve, deny, request changes, or take over manually * Reviewer decisions return to the WISMO case as structured values * Draft actions match policy and thresholds * Delivered-not-received cases escalate when proof is weak or value is high ## Phase 5: Expand Once Proven Goal: scale coverage after the quality loop is stable. Expand: * From chat to email and broader ticket groups * From low-risk proactive events to supplier and warehouse exceptions * From draft-only actions to approved write actions where policy allows * From a few condition labels to the full WISMO analytics taxonomy Monitor: * WISMO deflection rate by channel * First-touch resolution for WISMO tickets * Proactive no-ticket rate * Time from backend exception to first customer update * Percent of promised follow-ups sent before `next_follow_up_due_at` * Repeated-contact rate per order * Escalation rate by WISMO condition * Tool failure rate by system * CSAT or QA score by condition ## Batch Test Suite Before expanding live scope, build tests for: * Normal ETA within SLA * Processing within SLA * Split shipment with one delivered item and one pending item * Supplier backorder with unknown ETA * Supplier ETA update after unknown ETA * Warehouse pick delay * Label created but no carrier pickup scan * Carrier no movement * Delivery failed because of address issue * Return-to-sender * Delivered-not-received below threshold * Delivered-not-received above threshold * Fraud or address hold * Repeated customer contact * Tool failure or missing order data ## Launch Checklist * Deployments start in Testing mode * Write actions are disabled until approval paths are tested * Guardrails are configured for restricted states * Knowledge tags are scoped to WISMO policy, shipping SLAs, supplier backorders, warehouse fulfillment, carrier exceptions, and replacement/refund rules * Saved values include case ID, condition, last status sent, and next follow-up time * Analytics categories and attributes are configured before launch * Replay and batch tests pass for the launch channel ## Next Steps After rollout, review runs weekly for: * Repeated human corrections * Conditions with high escalation rate * Tool failures or stale data sources * Follow-up commitments that were late or missed * Customer replies that indicate the update was unclear * Conditions that should move from manual review to guarded automation