Your chat tool became a system nobody owns. Channels multiply, no rule says where work goes, and requests get lost in threads. We name an owner of the structure and write the routing rules. AI classifies channels, spots duplicates, and proposes what to merge; a person decides.
Common pain points
Too many channels in Slack or Teams — the count keeps growing and nobody decides what should and should not exist.
No owner of the channel taxonomy, so every team adds channels by reflex and the structure drifts.
No routing rule for what work or request goes in each channel, so the same conversation lands in three places.
No naming convention, so channels with similar names mean different things to different teams.
No archiving or consolidation rule, so dead channels stay alive and new joiners cannot tell which one is real.
When a request lands in the wrong channel, nobody routes it — it just sits in a thread the right team never reads.
The system has four parts. A channel taxonomy with a named owner of the structure. Routing rules that say what work goes in which channel. A naming convention and clear archiving rules. And AI that classifies how channels are actually used, spots duplicate and dead ones, and proposes what to merge or reroute. A person — the taxonomy or routing owner — decides; AI never archives or reroutes on its own.
How we work
We map how the team really uses the chat tool today and write the channel taxonomy with a named taxonomy owner and a routing owner.
We agree the routing rules (what work or request goes in each channel), the naming convention, and the rules for archiving and consolidation, and connect AI to classify channels and threads, detect duplicates and dead channels, and propose consolidation.
We set the review cadence so the taxonomy and routing stay current and hand over a runbook the owners operate and edit.
What we build
Area 1
We write the channel taxonomy for your team — the categories of channels that should exist (team, project, account, incident, social), how each is named, and what each is for. The naming convention is what makes "which channel is this" answerable without asking.
Deliverable
A channel taxonomy and naming convention: the categories of channels, the naming pattern, and the purpose of each category.
Area 2
We name the owner of the channel taxonomy as a system (the person who decides what categories exist), the routing owner (the person who decides where a request belongs when it lands wrong), and the routing rule per channel (what work or request belongs there). Ownership stops being implicit.
Deliverable
An ownership and routing map: the named taxonomy owner, the routing owner, and the rule for what work or request goes in each channel.
Area 3
We agree when a channel is archived (no activity for N weeks, no clear owner, duplicate purpose), when it is merged into another, and what stays. The point is that dead and duplicate channels stop being a permanent fixture and a new joiner sees a clean structure.
Deliverable
Archiving and consolidation rules: the criteria for when a channel is merged, kept, or archived, and who signs off.
Area 4
We connect AI to classify channels and threads by real use, detect duplicate and dead channels, and propose consolidation and routing rules from how the chat tool is actually used. What AI may never do — archive a channel, restructure the taxonomy, or reroute work on its own — is written down. AI proposes; the owner decides.
Deliverable
An AI capability map with the limits written: what AI classifies/detects/proposes, and what only the taxonomy or routing owner archives, reroutes, or restructures.
Area 5
We set how often the taxonomy and routing are reviewed, by whom, and how a structure change is decided — so the structure stays current between reviews and a new team's channels enter it properly.
Deliverable
A review cadence: when the taxonomy and routing are reviewed, who confirms, and how a structure change is decided.
Area 6
We hand the system over as a runbook: the taxonomy, the ownership and routing map, the archiving and consolidation rules, the AI limits, and the review cadence. The goal is that adding a new category or a new team is a small edit by the owner, not a fresh project.
Deliverable
A runbook with the taxonomy, ownership and routing map, archiving rules, AI limits, and review cadence the owners maintain.
The channel structure has a named owner, so the taxonomy stops drifting and there is somebody who decides what exists.
Every kind of work has a known channel and a routing rule, so the same conversation stops landing in three places.
A request that lands in the wrong channel gets routed to the right one because the routing owner exists.
Dead and duplicate channels are archived or merged on a clear rule, so a new joiner sees a clean structure.
AI classifies, detects and proposes — and a person decides, with the limit that AI never archives, reroutes or restructures on its own written down.
The owners operate and edit the runbook, so the next team or category is added properly, not piled on top.
No. A decision-capture system records the decisions a team makes — what was decided, by whom, when, reversible or not. This is the channel structure those decisions happen in: the taxonomy, the routing rules, the ownership of the structure. They sit next to each other; if your bottleneck is that decisions are not recorded, that is the decision-capture work.
No. Meeting reduction is about the calendar — which meetings exist, what asynchronous decision flow replaces them. This is about the chat tool — what channels exist, what each is for, who owns the structure. Different surface, different owner. They support each other but they are different systems.
No. This is not a one-off cleanup, and we do not pick or sell a chat tool. The deliverables are a channel taxonomy, an ownership and routing map, archiving and consolidation rules, an AI capability map with limits, a review cadence, and a runbook the owners operate. Whatever chat tool you use — Slack, Teams, or similar — we name it as an example only.
No. AI classifies channels and threads, detects duplicate and dead channels, and proposes consolidation and routing — but a person (the taxonomy or routing owner) decides what to merge, archive, or reroute. The rule that AI never archives, reroutes, or restructures on its own is written into the system, not left to default.
The review cadence is what makes that work — the owners review the taxonomy and routing on a schedule, and a structure change goes through a named decision. AI surfaces what has drifted (channels with no activity, duplicates, new patterns of work that need a category) so the review is informed, not blind; the owners decide.
It does not include a decision-capture system, a meeting-reduction system, picking or selling a chat tool, a one-off Slack cleanup, or an AI bot that archives, reroutes, or restructures channels on its own. If what you need is one of those, we will tell you and point you to the right work.
A spreadsheet became a system nobody designed: no field owner, versions that don't reconcile, errors going undetected. We write the rules, name the owners, a…
Read moreWorkflow automationThe operating context of each account is scattered across email, CRM, notes and chat — handovers lose half of it. We design a single view and name its owner.…
Read moreOperating cadenceDecisions get made in Slack and email, never written down, then reopened weeks later. We define what counts as a decision and where the log lives — and AI dr…
Read moreBook a 30-minute call to look at how your chat tool is used today and where work gets lost. We will talk through what the channel taxonomy should be, who owns it, the routing rules, and where AI can classify and propose. If the real issue is decision capture or meeting reduction, we will tell you and point you to the work that fits.
Book a 30-min call