NOTE: This is a walkthrough, not a document to fill in. Work through it with the plugin open in Claude.

Build your AI operating model, starting from nothing

You own AI delivery inside a business. Nothing is mapped. You have people asking what you are going to do, a vague sense of where the value might be, and a growing pile of notes from discovery conversations with nowhere to put them.

This is the shortest route out of that. By the end of an afternoon you will have one business function mapped properly: its processes, the steps inside them, where the time goes, and the first use cases worth doing.

The part people get wrong is starting from memory. Most of what you need has already been written down by someone in your organisation, for a completely different reason, and Claude can read it. That is the real reason to do this in Claude rather than in a platform: it is already sitting next to your documents, and it will take material you would not upload anywhere else.

What you will have at the end

• An org tree, built from your own org chart rather than from memory
• One business unit filled in, with the processes it owns
• One of those processes broken into steps, with the current state honest
• A list of what the documentation does not tell you, which is your agenda for the next conversation with that team
• Two or three opportunities logged against real processes rather than a wishlist
• A clear sense of how long the next function will take

What you will not have

A complete map of your company, and you should not try. A first pass across five or six functions is a couple of weeks of part-time work alongside your discovery conversations. Trying to do it in one sitting produces a map you do not believe and cannot defend.

Before you start: gather what already exists

The instinct is to sit down and describe your business from memory. Resist it. Most of what you need has already been written down by someone else, usually for a completely different reason, and reading it is faster and more accurate than recalling it.

An hour of gathering saves a day of guessing, and it produces a map other people recognise rather than one they have to be argued into.

Where the material already is

Nobody in your organisation calls these an operating model. Together they are most of one.

Asking for it

The specific ask works where the general one does not. “Do you have a process map or an SOP for the month-end close?” gets a yes more often than you would expect. “Tell me how Finance works” gets you a meeting in three weeks.

Ask for whatever exists rather than whatever is current. A three-year-old process map beats a blank page, because correcting a document is faster than authoring one, and people engage with something wrong far more readily than with something empty.

Step 1: Install the plugin

Ten minutes, no administrator needed.

In Claude, open Customize, then Plugins. Add the marketplace at github.com/kowalah-dev/kowalah-plugin, leave sync on, then find Kowalah in Discover and add it. In Claude Code it is two commands. Full instructions are in the install guide, and the plugin page explains what you are getting.

On first use Claude will prompt you to authenticate. Sign in with your work email. An email address Kowalah does not already know is fine, and you do not need to be invited first.

Step 2: Check where you landed

This matters more than it looks, and it takes one prompt.

I've just connected Kowalah. What can you see?

Your email domain decides where you land, and there are two outcomes:

A new organisation, created for you. Nobody from your company is in Kowalah yet, so you get your own organisation with you as its admin and an empty model. This is the normal case if you are reading this guide, and it is what the rest of the walkthrough assumes. You can author everything.

Your company’s existing organisation. Your company already works with Kowalah, so you have joined theirs, usually as a member. There will be a map already. Stop and talk to whoever runs the programme internally before adding anything, and ask them to raise your access if you need to edit.

Claude can tell the two apart. The reliable tell is the shape rather than the name: exactly one organisation where you are admin, a model with a single unit and no processes, and no vision. A new organisation is named from your email domain, so it will carry your employer’s name and look convincing.

Step 3: Point Claude at what you gathered

This is the reason to do this in Claude rather than in a platform: Claude is already sitting next to your material, and it will take documents you would not put anywhere else.

Use your connectors. If Claude already reaches your Google Drive, OneDrive, SharePoint, your CRM or your call transcripts, it can go and find things without you hunting for them.

Search our SharePoint for anything that looks like a process map, an SOP
or an org chart for Finance, and tell me what you found before you read
any of it in detail.

Upload the rest. Anything not connected, or anything sensitive enough that you would rather it were not in a shared drive, goes straight into the conversation.

What lands where

This is the question people ask before they upload anything, so here it is precisely.

The document stays in your Claude conversation. What gets written into Kowalah is the structure you and Claude derive from it: unit names, process names, the steps, what each step takes in and puts out, and how it runs today. There is no upload path into the model at all.

So a sensitive SOP, a draft reorganisation chart or a set of call transcripts can inform the map without ever becoming part of it. That is a different trust decision from loading the same file into a vendor’s platform, and it is usually the difference between mapping the real process and mapping the sanitised one.

Step 4: Set the context once

Tell Claude who you are and what you are doing, at the start of the thread. It changes every answer that follows.

I'm the AI Operations Lead at [company]. We're [size] people in [industry].
Nothing is mapped in Kowalah yet. I've got our org chart, the finance
close checklist and the process maps from our ERP rollout. I want to map
one function properly today rather than sketch the whole company.
Where should we start?

If you already know which function to start with, say so. If you do not, a good default is the one where you have already had the most discovery conversations, because you will be able to answer the follow-up questions without guessing.

Step 5: Build the org tree from the chart

Business units are the top level of the map: the divisions or functions the company is actually organised into. If you have an org chart, this takes one prompt rather than twenty minutes of typing.

Here's our org chart. Build the unit tree from it, top two levels only,
with the leader and approximate headcount for each. Ask me where it's
ambiguous rather than guessing.

Top two levels is usually the right depth. Going deeper produces a tree you will spend the afternoon maintaining instead of a map you can use. You can always push into a unit later when you map its processes.

The org chart is the reporting line, not how work flows. Order to cash runs through Sales, Operations and Finance, and the chart will not tell you that. Say so when it comes up, and let the processes cross units rather than forcing them into one.

Add the siblings you are not mapping today anyway. A tree with eight units and one of them filled in tells a better story than a single unit on its own, because it makes the gaps visible.

If you have no org chart to hand, describe it instead:

Add Finance as a unit. It reports to the CFO, has around 40 people,
and covers financial control, accounts payable, accounts receivable
and financial planning.

Step 6: Map a process from its documentation

The part that carries the value. Start from the document rather than from memory.

Here's the month-end close checklist. Turn it into a process under
Finance with its steps. For each step capture what goes in, what comes
out and who does it. Flag anything the document doesn't tell you.

The flags are the most useful thing you get back. A checklist tells you the order of operations and almost never tells you how long a step takes, who does it when that person is on holiday, or what happens when it fails. That list of gaps is your agenda for the conversation with the team, and it is a far better opening than an empty page.

Where documentation runs out

Some processes are genuinely not written down anywhere, and every documented one has undocumented reality around it. That is where you talk it through.

The checklist stops at "reconcile intercompany". Walk me through
capturing what actually happens in that step. I'll describe it and
you capture it. Ask me what you need.

Describe it the way you would explain it to a new joiner: what happens, who does it, what it takes, and what goes wrong. Claude will ask about what you skip, and the questions are where you find out what you do not know yet.

Record the real version, not the documented one. A map of how things are supposed to work is worth nothing. If step four is done in a spreadsheet that one person maintains and the SOP says it happens in the ERP, record the spreadsheet. The gap between the document and the practice is the most valuable thing you will find all afternoon, and those are exactly the steps where the value is.

Step 7: Find where it hurts

With the steps captured, ask the question you came for.

Looking at these steps, where is the cycle time actually going, and which
steps have never been measured?

Which of these steps could realistically change this quarter, and what
would we need to prove first?

Then log what is worth doing, against the real process rather than into a separate list:

Log the reconciliation step as an opportunity. Impact is high, we think
it's three days of the nine. Confidence is medium, we haven't measured it
properly yet.

Scoring honestly matters more than scoring high. Confidence is the number people inflate, and an opportunity you have not measured should say so.

The rest of the afternoon

You have a shape now. Two useful ways to spend what is left:

Go wider. Add the processes each of your other units owns, without the steps. Half an hour of this gives you the coverage view, which is what tells you where to concentrate next. Value concentrates in a small number of domains and you cannot see which until you have the breadth.

Go back and check. Take what you mapped to one person who does the work and let them correct it. Being corrected is worth more than being approximately right, and it is the fastest way to establish what you are actually for.

Show me the coverage across all units, and where the gaps are.

What to do next

The next function. It will take about half as long. Repeat until you have a first pass across the functions that matter, then stop and build something.

Pick your domains. Once four or five functions are mapped, choose the two or three where AI moves a number the business already cares about, and concentrate there. The first 90 days guide covers how to choose and how to defend the choice when everyone wants to be first.

Bring the process owners in. This is where solo mapping stops being enough. A map you built alone is your account of how the business runs. It becomes true when the people who own those processes confirm their own and keep them current. That is a different kind of artefact: it stops being a document you maintain and becomes an operating model the organisation maintains.

Implementation notes

Map in the conversation, not afterwards. The point of doing this in Claude is that it happens while you are still talking to people about how their work runs. A discovery conversation in the morning and a mapping session in the afternoon loses half of what you heard. Map as you go.

Gathering is the hour that pays for itself fastest. It is also the part people skip, because it feels like preparation rather than progress. A map built from documents lands differently in the room: you are showing a team something assembled from their own material and asking where it is wrong, rather than showing them your interpretation of a conversation.

Coarse beats complete. The model is a decision-making instrument, not documentation. If a level of detail would not change which use case you pick next, you do not need it yet.

Record who told you. When you capture a process or log an opportunity, note who described it. It costs nothing and it means you can go back to them when it reaches the top of the list, which is how a backlog builds advocates.

Your first map will be wrong. Write it anyway. Correcting a draft in front of a team is a conversation; asking them to describe their work into a blank page is an interview. The first is faster and people prefer it.