> For the complete documentation index, see [llms.txt](https://specs.govstack.global/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://specs.govstack.global/service-patterns/2.-functional-patterns/other-ways-to-access-a-service.md).

# 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.&#x20;

#### **Use this pattern when:**

* not all users can access the primary (often digital) channel
* services must support assisted, offline, or in-person access.&#x20;
* 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.](/service-patterns/3.-step-patterns/service-sheet.md)

#### 2. Explain how alternative access works

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

Make it clear:&#x20;

* 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](/service-patterns/2.-functional-patterns/schedule-an-appointment.md)
* [Send a notification](/service-patterns/3.-step-patterns/send-a-notification.md)
* [Outcome](/service-patterns/3.-step-patterns/outcome.md)

***

## Considerations

#### **Equity and inclusion**&#x20;

* 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.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://specs.govstack.global/service-patterns/2.-functional-patterns/other-ways-to-access-a-service.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
