Other ways to access a service

Provide alternative channels for users to access and complete a service when the primary route is not suitable. All channels must lead to the same service outcome.

Use this pattern when:

• not all users can access the primary (often digital) channel

• services must support assisted, offline, or in-person access.

• policy or inclusion requirements mandate alternative routes

Steps

1. Make alternative routes visible

Users should be made aware that there are other ways to access the service.

Examples

• phone support (incl. SMS alerts)

• in-person appointments

• assisted digital

• paper-based routes

• delegated or proxy access

Design guidance

• Alternatives should be discoverable early, not only after failure.

• Present alternatives as legitimate, not secondary or “last resort”

Show the alternative routes available on the service sheet.

2. Explain how alternative access works

Tell users what to expect if they choose a different route.

Make it clear:

• how to start the alternative route

• what information will be needed

• whether progress can be carried across channels

• any differences in timing, effort or costs

3. Handover into the alternative channel (if relevant)

The service should support a clean transition into the chosen route.

Examples:

• booking an in-person visit

• generating a reference number

• creating a case for assisted handling

• issuing instructions or documents

Use these step patterns where applicable:

• Schedule an appointment

• Send a notification

• Outcome

---

Considerations

Equity and inclusion

• Alternative routes should not reduce eligibility or service quality.

• Timeframes and costs associated with alternative channels should be transparent.

Continuity

• Where possible, users should not have to repeat information when switching channels.

• Staff and systems should have shared visibility of progress.

Rules and validations on assisted journeys

• Assisted access should follow the same service rules and validations.

• Staff should use the same underlying service definitions.