Nobody sensible hires five people and then figures out what they'll do. You define the jobs first. Then you hire for them.
With bots, it's tempting to skip that step. Bots are quick to set up. So people build three bots and then try to make them work together. It's easier the other way around.
The process approach in ISO
ISO is built on the process approach: understand and manage activities as connected processes that work together as a system. Each process has inputs, outputs, an owner, and a way to check it.
It's one of the seven quality management principles. See The seven principles, for bots.
Draw it first
Before any bot, draw the work:
- List the steps. What actually happens, start to finish.
- Draw a box for each step. One job per box.
- Draw arrows for handoffs. What passes from one box to the next.
- Label each arrow. What exactly is handed over.
- Mark the gates. Where does a person need to say yes?
Paper and a pen are fine.
Test every arrow
For each arrow, ask: does this step actually need the result of the one before it?
If not, it's a fake arrow. The steps can run side by side, or the arrow goes. Fake arrows slow things down and spread mistakes down the chain. See Data, process and schema up front.
Then decide who does each box
Now you can decide, box by box:
| Box | Who | Why |
|---|---|---|
| Pull this week's orders | Plain code | Exact, repeatable |
| Flag unusual orders | Bot | Needs judgment |
| Draft the supplier email | Bot | Writing |
| Approve and send | Person | Ships outside |
| File the record | Bot | Routine, rule-based |
Not every box needs a bot. Some are better as plain code, because code doesn't guess. Some need a person. Bots fit the boxes that need judgment and writing.
One bot or several?
If several boxes are similar and small, one bot might do them all. If they need very different instructions, tools or access, split them. A bot with one job is easier to check. See Multi-bot teams.
A real example
Our AN Creation office has a defined set of project stages, each with an owner and a record, and a "routes and flow" skill that describes how work moves between them. The bots were written to fit that map. The map came first.
This site works the same way: research, draft, approve, publish. Four boxes, three arrows, one gate before publishing.
What this means for you
- Draw the process before building bots.
- One job per box, a label on every arrow.
- Delete fake arrows.
- Pick code, bot or person for each box.
- Mark the gates.
The map is cheap. Rebuilding a tangled team of bots is not.