> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kowalah.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Processes and steps

> Read a process in the operating model: its steps and dispositions, KPIs, what implements each step, and how processes connect.

A process is the durable unit of the operating model. It is a piece of recurring work that a unit owns, such as overdue receivables collection, quote to order, or new-hire onboarding. Opening a process shows you how that work runs today and where it is heading.

## The step sequence

The heart of a process is its **step sequence**, laid out like a tube map: a handful of coarse steps in order, each shown as a row. Processes are deliberately kept to roughly 5 to 15 steps. If a process needs 40 steps to describe, it is really several processes.

Each step row shows:

* The **step name**, a short verb phrase such as "Prioritise accounts to chase."
* The **current disposition** as a coloured chip: Human, AI-assisted, Automated, or AI-autonomous.
* The **target disposition**, where one is set. Steps with a gap between current and target are highlighted, because they are the redesign opportunities.
* The **platform** that does the work, where relevant, and the **owner** accountable for the step.

<Tip>
  A process can be **linear** (a sequence with a start and end) or **cyclical** (a loop that repeats, like a monthly close). The shape is shown on the process so the sequence reads correctly.
</Tip>

## Understanding a step

Open a step to see the detail behind it. Alongside its name and description, a step can carry:

| Field                              | What it tells you                                                                                              |
| ---------------------------------- | -------------------------------------------------------------------------------------------------------------- |
| **Current and target disposition** | How the work is done today and where it is heading.                                                            |
| **Constraint**                     | Whether this step is a bottleneck that holds back the whole process.                                           |
| **Coordination burden**            | How much back-and-forth, chasing, and handoff the step involves. High-coordination steps are prime AI targets. |
| **Platform**                       | What does the work: Claude, ChatGPT, Copilot, Gemini, a hub agent, RPA, an internal system, or other.          |
| **Owner and role**                 | Who is accountable, and which business role performs it.                                                       |
| **Volume and time**                | How often the step runs and how long it takes, so its cost in human time is visible.                           |
| **Risk and exception notes**       | Governance notes, and what happens when the step needs a human.                                                |

<Note>
  When a step's target is **AI-autonomous**, it carries an **escalation trigger**: the condition under which the agent hands back to a person. Autonomy always has a defined human fallback.
</Note>

### Why constraint and coordination matter

The operating model ranks your redesign backlog by **constraint and coordination burden**, not by whatever looks quickest. A step that is both a bottleneck and heavy on coordination is where AI creates the most value, because easing coordination work, the "work behind the work" of scheduling, chasing, and reconciling, is often what moves the numbers. Flagging these on a step is how the highest-value opportunities rise to the top.

## What implements a step

Once a step is more than Human, you can see *what* implements it. A step can link to one or more:

* **Accelerators** from your [accelerator library](/platform/accelerators).
* **Hub agents** that run the step autonomously.
* **External** tools, recorded with a name and link.

Each implementation has a status of planned, live, or retired. This is also how the map stays honest: retire an agent, and the step visibly loses its implementation, which is a prompt to revisit its disposition.

## Measuring value with KPIs

Coverage shows where AI is. **KPIs** show whether it is working. A process can carry a small number of outcome KPIs, the numbers a leader actually recognises, such as days sales outstanding, cycle time, or recovery rate.

Each KPI tracks three values:

* **Baseline** — where you started, signed off up front.
* **Current** — where it is now.
* **Target** — where you are aiming.

KPIs know their direction (whether up or down is good), so progress reads correctly at a glance. Keeping KPIs to a handful per process is deliberate. This is a scoreboard that proves a redesign worked, not a business-intelligence tool. Your existing analytics stack still does the deep analysis.

## How processes connect

Real work crosses process boundaries. A process can have **connections** to others:

* A **handoff**, where one process passes work to another.
* A **feed**, where one process supplies information another depends on.

Connections can be pinned to the specific steps where the handoff happens, and the map highlights when a connection crosses a unit boundary, which is often where coordination cost and delay hide.

## Linked initiatives

A process shows the delivery work attached to it: the [Opportunities](/platform/opportunities), [Deliverables](/platform/projects/deliverables), and [projects](/platform/projects/overview) that are changing it. This is what makes an initiative legible as *a change to a specific process*, with an address in the business and a value hypothesis, rather than a free-floating project.

## What's next

<CardGroup cols={2}>
  <Card title="Owning and improving a process" icon="pencil" href="/platform/operating-model/owning-and-improving">
    Edit steps, set targets, and suggest changes
  </Card>

  <Card title="From map to delivery" icon="git-pull-request-arrow" href="/platform/operating-model/from-map-to-delivery">
    Turn a redesign gap into delivered work
  </Card>
</CardGroup>
