Your team's tool map

The situation

Your team has licenses for two assistants plus the one built into the office suite, and nobody has written down what goes where. Ask four people how to draft a client summary and you get four answers, each delivered with total confidence, none of them the same. The analyst who started on Monday has already asked three of them. By Friday she will settle on whichever tool she used at her last employer and quietly stop asking. Every one of those private, undocumented routing decisions is a decision your team makes a hundred times a week without ever having made it once.

The principle

A team's tool map routes work shapes to tools, and the moment it starts ranking vendors it stops being a map and becomes an argument.

Rankings rot. Any sentence of the form "X is better at Y" is stale within a release cycle, and it never told a new joiner where to put a task anyway — it told them who to argue with. Routing does not rot, because the shapes of work do not change. One document. Across the work. Gather, then finish. And the things that go nowhere near an AI tool at all.

Write the shapes down and the tool names become a single column you can edit in under a minute when a license changes. That is the difference between a page that survives a procurement decision and a page that gets deleted by one.

Worked example

Shown here in ChatGPT.

One page, four blocks, in this order. The order matters: a new joiner reads until their question is answered and then stops.

TEAM TOOL MAP — <team> — owned by <role> — last reviewed <date>

1. DEFAULT
   Not sure? Start here: <tool + surface>.
   Say the rule first: inside one document, or across the work.

2. ROUTING TABLE
   | Work shape | What it looks like here | Where it goes | Why |
   ...one row per shape you actually meet. Ten rows is plenty.

3. NOT A ROUTING DECISION
   Work that does not go into a chat at all: volume builds (the last row
   of block 2), and anything on the team's AI ground rule RED list —
   that page owns the data question and lives at <where>.

4. HOW THIS CHANGES
   <role> owns this page. Reviewed every <interval>.
   Propose a change by <mechanism> — bring the task, not the tool.

Block 2, filled in for a mid-market insurance broker's operations team. Their licenses are ChatGPT plus the assistant in their office suite. Your tool names will differ; the shapes will not.

| Work shape       | What it looks like here          | Where it goes           | Why |
| One document     | Tightening a renewal letter      | Assistant inside Word   | The letter is the deliverable; edits belong in the file |
| Across the work  | "Which policies lapse in Q3?"    | ChatGPT, Renewals project | Answer spans 200 records and lands in a new table |
| Gather, then     | Quarterly client review pack     | Gather in ChatGPT, finish | Three source systems, one deliverable |
|   finish         |                                  |   in the deck             | |
| Neither          | 400 broker statements a month    | Ops queue — ask the ops lead | Volume, not shape: this is a build, not a chat |

Note what the Why column is for. It is not justification. It is the thing that lets someone route a task the table does not list. Rows run out on their second day; reasons generalise.

In your tool

The Where it goes column is where most maps fail. A vendor name is not a destination — each of these has several surfaces, and "use ChatGPT" does not tell a new joiner whether to open a project or a blank chat. Name the surface.

Product surfaces checked 2026-08-04.

One naming trap belongs on your page too. GitHub Copilot is a different product with its own repository instruction files, and it is outside this course's scope. If your team has both, write both names out in full — a page that just says "Copilot" routes people to whichever one they already had open.

Try it

Write block 1 and three rows of block 2, for shapes you actually met this week. Five minutes. Use your real tool names and your real license list — a map that routes work to a tool nobody has access to is worse than no map, because it teaches people to ignore the page.

You are done when someone who joined this month could take a task off your list, find its row, and route it without asking you. Test it exactly that way: hand them the page and a task, and say nothing.

Common failures

• The ranking map. A page of "this one is better at writing, that one is better at numbers." It ages in weeks, it reopens the same debate every time it is mentioned, and it still does not tell anyone where to put a task.
• The map nobody owns. No name in block 4, no review date. A page with no owner is wrong within a quarter, and a wrong page is worse than a missing one, because people keep quoting it after it stops being true.
• The feature inventory. Every capability of every license, four pages, alphabetised. Nobody reads past the first screen. A map is a routing table for the ten shapes your team meets, not documentation for the products your team bought.