Skip to main content

What it does

Routing | Service Location - v0.2 works out where the caller needs service and, from that, which of your routing endpoints should take the call. In one step it:
  1. asks which state and suburb the caller needs service in,
  2. matches their answer to a known locality and reads it back for the caller to confirm,
  3. if nothing matches, asks for a larger nearby town or suburb, a postcode, or both,
  4. looks up the routing endpoint that covers the confirmed area, following your team’s location routing rules, and
  5. if several endpoints cover the area, offers them to the caller by name and lets them choose.
It is a composite tool: the whole exchange runs behind a single step. It never dials. It hands the matched endpoint to your script in {{route.endpoint_id}}, and a Handoff step after it makes the transfer. Keeping the transfer in your own flow lets each script choose warm or cold transfer, its own handover wording and its own fallback. Which endpoints cover which areas is set up under Numbers & Routing: the endpoints’ Coverage and the team’s Routing settings. See Location Routing.

Use cases

  • Route to the local branch or franchise. A national number sends each caller to the service centre that covers their suburb.
  • Offer a choice of nearby centres. Where more than one location covers an area, the caller picks the one they want.
  • Capture the service location only. With Lookup Mode set to locality only, the tool confirms the suburb, state and postcode and stops there, for scripts that need the location but route some other way.

Inputs


How it runs

  • Postcode up front. If the caller gives a postcode in their first answer, the tool uses it straight away.
  • Read-back. The matched locality is always read back for a yes or no. If the caller says no and names another place, that place is tried once more.
  • Ambiguous names. If a suburb name exists in more than one place, or the caller didn’t say a state, the tool asks which one they mean.
  • Choosing a centre. If more than one endpoint covers the area, the tool names them and asks which the caller would like.
  • Closed endpoints. An endpoint whose schedule is closed but that forwards elsewhere still counts. The Handoff step follows the same forwarding chain. When every covering endpoint is closed with nowhere to forward, the tool finishes false with the status unavailable.
  • Lookups that time out are retried once, silently, before the tool gives up with the status error.

Outputs

Variables this tool writes

The route namespace also holds the tool’s own working fields (the inputs, the caller’s words, the candidates it proposed). They are private to the tool, and the next use of the tool in the call overwrites the whole namespace. If a later step needs a value after that, map the output onto a custom variable.

Routing and wiring

Wire the tool to two Handoff steps: one for the matched endpoint and one for your fallback.
  • true: the locality is confirmed. In endpoint mode, dial {{route.endpoint_id}}. In locality-only mode, read the {{route.locality_*}} values and carry on.
  • Otherwise: branch on {{route.status}}. fallback and unavailable both go to the fallback Handoff. error means the lookup itself failed; treat it the same way.
  • The endpoint’s own schedule, fallback and forwarding rules apply when the Handoff step dials it. You don’t need a separate opening-hours check unless the script should say something specific out of hours.
  • {{route.endpoint_id}} holds a routing endpoint, never a phone number. It only works in a field that takes a routing endpoint, such as the Handoff tool’s Routing Endpoint.
  • The postcode is collected by voice only.

Next Steps