The Cartographers' Table

What mapping actually involves

We follow real work through your business. A specific order, a specific claim, a specific onboarding — chosen with you, then traced from the moment it arrives to the moment it is finished, through every person and system it touches.

This is deliberately not a workshop. Workshops produce the process people believe they follow. Following the work produces the process they actually follow, and the distance between the two is usually where the problem lives.

Observation, not interview

Time spent watching the work happen, with the people doing it. Interviews come after, to check what we saw, not to establish it.

Systems inventory

What you own, what it is genuinely used for, and what is being done in a spreadsheet beside it because the system could not be made to do it.

Handoff and queue analysis

Where work waits, where it doubles back, and where the same information is entered a second time. Waiting and re-entry are usually the two largest costs and the two least visible.

The map itself

A drawn artefact you keep, in a form your team can read and correct. Not a slide deck. If it cannot be argued with, it is not useful.

What comes out of it

A current-state map, a target-state map, and an honest account of the distance between them — including which parts of that distance are worth crossing and which are not.

Often the most valuable finding is that a process everyone complains about is fine, and the real cost sits somewhere nobody was looking. That finding is only available to someone with no product to sell you.

Where it stops

Mapping can be the whole engagement. Plenty of companies need the drawing and nothing else, and then go and fix things themselves with their own people.

We would rather do that well than manufacture a build. If the map says your problem is a policy or a reporting line rather than software, the map will say so.