Skip to main content
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