The decision tree from \"phone rings\" to \"human answers\" has 7 canonical strategies. Each has different math, different agent fairness, and different customer-experience trade-offs.
\nOne number forwards to one destination. The simplest case.
\n- connect:\n to: +13105551111\n timeout: 30\nWhen to use: single-agent operations, small businesses with one phone line, after-hours forwarding to on-call. Trade-off: zero redundancy — if the destination doesn't answer, the call fails.
\nRing every agent at once. First to answer wins.
\n- connect:\n to:\n - +13105551111\n - +13105552222\n - +13105553333\n timeout: 30\nWhen to use: small teams (3-5 agents), urgent service categories where first-available wins (emergency plumbing, locksmiths). Trade-off: disruptive — every phone rings every call. Agents annoyed. Higher answer rate than hunt group but worse for agent focus.
\nTry agent 1, then agent 2, then agent 3 in sequence. Each gets the full ring timeout before falling through.
\n- connect:\n to: +13105551111\n timeout: 15\n- connect:\n to: +13105552222\n timeout: 15\n- connect:\n to: +13105553333\n timeout: 15\n- play: say:All agents are busy, please leave a message\n- record_call: {}\nWhen to use: strict seniority hierarchy (senior agent gets first shot), or after-hours escalation chains (try office → try cell → try backup). Trade-off: unfair — agent 1 takes all the calls, agents 2-3 starve.
\nCycle through agents so each gets roughly equal call volume. Requires state (which agent was last called).
\n- request:\n url: https://your.api/get-next-agent?queue=sales\n method: GET\n save: routing\n- connect:\n to: \"${routing.next_agent}\"\n timeout: 30\n- request:\n url: https://your.api/release-agent\n method: POST\n body:\n agent: \"${routing.next_agent}\"\n call_id: \"${call.id}\"\nYour API tracks the rotation and returns the next agent in line. On call end, mark the agent available again.
\nAgents with higher capacity get more calls per cycle:
\nagents = [\n (\"+13105551111\", 3), # gets 3 of every 6 calls\n (\"+13105552222\", 2), # gets 2 of every 6 calls\n (\"+13105553333\", 1), # gets 1 of every 6 calls\n]\nWhen to use: call centers with fungible agent skills, fairness matters. Trade-off: requires external state, slightly slower routing decision.
\nMatch the caller to an agent with relevant expertise (language, certification, product knowledge). Requires caller-intent capture and agent-skill metadata.
\n- prompt:\n play: say:Press 1 for billing, 2 for technical support, 3 for new sales\n max_digits: 1\n- request:\n url: https://your.api/route?skill=${prompt_value}\n method: GET\n save: route\n- connect:\n to: \"${route.agent}\"\n timeout: 30\n- ai:\n prompt:\n text: |\n Identify the caller's reason. Call route_to_agent with one of:\n billing, technical, sales, retention.\n SWAIG:\n functions:\n - function: route_to_agent\n parameters:\n type: object\n properties:\n skill: { type: string, enum: [\"billing\", \"technical\", \"sales\", \"retention\"] }\n data_map:\n webhooks:\n - url: https://your.api/route\nWhen to use: multi-product or multi-language operations, complex L1/L2/L3 support tiers. Trade-off: highest ops complexity, requires accurate skill tagging in the agent directory.
\nRoute by caller's location — area code, IP/ANI lookup, or stated location.
\n- request:\n url: https://your.api/geo-route?phone=${call.from}\n method: GET\n save: geo\n- connect:\n to: \"${geo.regional_office}\"\n timeout: 30\nThe API does an area-code-to-region lookup or queries an LRN database for higher accuracy.
\nWhen to use: multi-office businesses where local presence matters, regulated industries needing in-state agents (insurance, real estate). Trade-off: area code is unreliable for mobile users; LRN lookups cost money.
\nDifferent destinations during different hours. See business hours logic for the full pattern.
\n- cond:\n when: \"is_business_hours()\"\n then:\n - connect:\n to: +13105551111\n else:\n - connect:\n to: +13105559999 # after-hours service\nWhen to use: any operation with non-24/7 hours.
\nReal production routers combine strategies. Common hybrids:
\ninbound call\n ├─ if after hours → voicemail\n ├─ if business hours\n │ └─ IVR captures skill\n │ └─ round-robin among agents with that skill\n │ └─ if no skill match → general queue\ninbound call\n └─ geo-route to regional office\n └─ skill-based routing within that office\n └─ overflow to nearest neighboring office\ninbound call\n └─ ring-all 3 senior agents (15 sec timeout)\n └─ if no answer, hunt through junior agents\n └─ if no answer, voicemail\n| Strategy | Setup complexity | Answer rate | Agent fairness | Customer experience |\n|---|---|---|---|---|\n| Simple forward | Trivial | Low | N/A | Mediocre (no redundancy) |\n| Ring all | Low | Highest | Poor (everyone disrupted) | Good (fastest answer) |\n| Hunt group | Low | Medium | Very poor | OK (with reasonable timeouts) |\n| Round-robin | Medium | Medium-High | Excellent | Good |\n| Skill-based | High | Medium-High | Configurable | Excellent |\n| Geo-based | Medium | Medium | Variable | Good (local touch) |\n| Time-of-day | Low | N/A | N/A | Critical for hours-of-operation |
\nRouting decision time impacts customer experience. Targets:
\n| Pattern | Decision overhead |\n|---|---|\n| SWML inline cond | < 50ms |\n| SWML + external API | 100-500ms |\n| SWML + AI classification | 2-5 seconds |\n| Multi-step IVR + API | 5-15 seconds |
\nCaller perception: silence under 1 second feels normal; 1-3 seconds feels like a hiccup; 3+ seconds feels broken unless filled with \"one moment\" TTS.
\nRound-robin and skill-based need state. Three storage options:
\n| Option | Latency | Durability | Complexity |\n|---|---|---|---|\n| Redis | < 5ms | Volatile | Low |\n| Supabase | 30-100ms | Durable | Low |\n| SignalWire global_data | inline | Per-call only (not persistent across calls) | Trivial |\n| In-memory cache | < 1ms | Lost on restart | Low |
\nFor round-robin, a Redis counter with atomic increment is the cleanest pattern. For skill-based, durable state (Supabase) so agent skills survive restarts.
\nUse an AI agent as the routing layer:
\n- ai:\n prompt:\n text: |\n You are a phone receptionist. Identify the caller's needs and route them.\n Use route_caller to direct them based on their intent.\n SWAIG:\n functions:\n - function: route_caller\n parameters:\n type: object\n properties:\n department: { type: string, enum: [\"sales\", \"support\", \"billing\"] }\n urgency: { type: string, enum: [\"normal\", \"urgent\"] }\n data_map:\n webhooks:\n - url: https://your.api/ai-route\nThe AI handles disambiguation, language detection, and intent capture — much better than DTMF IVR for complex routing.
\nconnect verb documentation