> 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/guide-users-through-a-service.md).

# Guide users through a service

Help users navigate a service journey that involves multiple functions. Make progress visible and support smooth transitions between functions, so users can complete a service without confusion

**Use this pattern when:**

* a service includes more than one functional pattern
* users may need to complete tasks in a specific order
* users may pause and return to the service later
* the service needs clear review or completion points
* functions such as Scheduling or Request information are part of a wider flow

**Do not use this pattern when:**

* the service consists of a single, simple interaction
* no progression, review, or re-entry is required
* the service is purely informational

## Steps

{% @mermaid/diagram content="---
config:
theme: redux
layout: dagre
-------------

flowchart LR
A\["Service sheet"] --> B{"Multiple functions? <br>(Check, Pay, Visit)"}
B -- Yes --> C\["Task list"]
B -- No --> E\["Route user to function"]
C --> E
E --> F{"Is the function complex?<br>"}
F -- Yes --> G\["Overview"]
F -- No --> H\["Proceed through steps"]
G --> I\["Complete function"]
H --> I
I -- If task list --> J\["Return to task list"]
J --> K{"Are there remaining\nrequired functions?"}
K -- Yes --> E
K -- No --> L\["Check answers <br>(if needed)"]
L --> M\["Outcome"]
I -- If no task list --> K

A@{ shape: rounded}
C@{ shape: rounded}
G@{ shape: rounded}
L@{ shape: rounded}
M@{ shape: rounded}
" %}

<details>

<summary><strong>Example user flow</strong></summary>

<figure><img src="https://content.gitbook.com/content/u8moxPbFWK9pTxPYNIyh/blobs/ke0vtWRnUnruvtuB5ZQB/Guide%20users%20through%20a%20service.png" alt=""><figcaption></figcaption></figure>

</details>

#### 1. Assess if service contains multiple functions or transitions

This decision determines whether users need a service-level structure to understand and manage progress.

* If yes, use [task list](/service-patterns/3.-step-patterns/task-list.md) to show the overall service structure and support pause and return.
* If no, route users directly into the function without introducing additional structure.

Use this decision when a service includes multiple tasks, can be completed over time, or allows tasks to be completed in different orders.

#### 2. Assess if the function is complex?

This decision determines whether users need orientation within a function.

* If yes, use a [Before you start page](/service-patterns/3.-step-patterns/before-you-start.md) to explain what the function involves, and [check your answers](/service-patterns/3.-step-patterns/check-answers.md) to show progress, and allow review.
* If no, proceed directly through the function’s steps.

Use this decision when a function includes multiple steps, branching logic, prerequisites, or the possibility of pause and return.

***

## Considerations

* Avoid duplicating orientation at both service and function levels unless needed.
* Support non-linear progress and return.
* Use structure, not hand-off screens, to connect functions.

<br>


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://specs.govstack.global/service-patterns/2.-functional-patterns/guide-users-through-a-service.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.
