Walk into almost any SMB that’s been on Microsoft 365 for a few years and open their list of teams. I’ll wager it’s long, it’s inconsistent, and at least a third of what’s there hasn’t had a message posted since someone left the business. There’s a “Project Handover”, a “Project Handover 2”, and a “Sales – DO NOT USE”. Nobody remembers who owns half of them.
For years I treated that as a tidiness problem — annoying, but low stakes. I don’t anymore. The moment a client turns on Microsoft 365 Copilot, that untidy structure stops being cosmetic and starts shaping the quality of the answers they get.
Fewer teams than the client thinks they need
The most common structural mistake I see is a team for every project. It feels organised in the moment and it ages terribly. Six months on, the client has forty teams, most of them half-dead, and no one can find anything.
The fix I push is boring and it works: a team should map to a group of people who work together regularly, not to a task. Channels carry the topics. So instead of spinning up “Q3 Campaign”, the marketing team already exists, and Q3 Campaign is a channel inside it. When the campaign ends, you archive a channel, not a whole team. The people, the files in the SharePoint site behind it, and the history all stay in one sensible place.
I tell clients to design the teams first and resist the reflex to create. Every new team is a new SharePoint site, a new permissions boundary, another thing to govern.
Private and shared channels are the other trap. They have their place, but I see them thrown around to hide a conversation between two people, and every one of them quietly spins up its own SharePoint site behind the scenes. I treat them as the exception, not the reflex. If half your channels are private, you haven’t structured a team — you’ve built a warren.
Ownership is a structural decision, not an afterthought
The other quiet failure is ownership. A team gets created by whoever had the idea, they leave, and now it’s an orphan — no owner, no one to manage membership, guest access frozen in whatever state it was left in.
I won’t stand up a team now without at least two owners named on day one. I set expiration and archiving policies so dormant teams get flagged instead of accumulating forever, and I lean on Purview and the group settings in Entra to keep naming and guest access consistent across the client’s tenant. Structure isn’t just the shape of the teams. It’s who’s responsible when the shape needs to change.
Structure is what Copilot actually reads
Here’s the part that’s changed my thinking. When a client asks Copilot in Teams to summarise a project or pull together what was decided, Copilot reads across their channels, chats and the files sitting in those SharePoint sites. If that content is scattered over a dozen abandoned teams with three copies of the same document, the answer comes back vague or wrong — and the client blames Copilot.
It isn’t Copilot. It’s the structure underneath it. A tidy, well-owned set of teams is the difference between a genuinely useful summary and a confident piece of nonsense.
So my order of operations for clients has flipped. I do the Teams structure work before we switch Copilot on, not after they complain. Get the containers right, get ownership right, get the content living in the right place — then let Copilot loose on something worth reading.
Tidy was always nice to have. Now it’s what makes the AI worth paying for.
CIAOPS 