How to write team agreements before comparing collaboration tools

The tools in this category are close enough that the choice between them rarely decides whether your team communicates well. What decides it is a set of agreements about how people are expected to talk to each other. Most organizations buy the tool first and never make the agreements at all.

So this page inverts the usual order. Write down how you intend to communicate, then choose the product that supports it, and stay open to the conclusion that you do not need a new one.

What to take away

Write the agreements first

Six decisions, none of them technical. Make them explicitly and the tool matters much less; skip them and no product will save you.

Which medium carries which kind of message. Something that needs a decision, something that needs an answer today, and something that needs to be findable in a year are three different things. In practice that means a document or an email in Outlook or Gmail for the first, chat for the second, and a durable record in mail or a wiki for the third. The collaboration overview sets out why chat handles the third one badly, and the agreement you need is where that material goes instead.

What response time each medium implies. If nobody says, everyone assumes a different number, and the assumption is usually "immediately". That single unstated expectation causes most of the exhaustion attributed to these tools.

What is open by default. Whether conversations that affect other people happen where those people can see them. This is the difference between an organization with a searchable history and one where the answer is always in somebody's private messages.

Who may create a channel, and what happens to it when it goes quiet. Decide the naming pattern and the archiving rule now. Retrofitting either onto four hundred channels does not happen.

Where automated messages go. Into their own places, from the first connection, never into the channels people are trying to work in.

When people are not expected to be present. Working hours, time zones, and what an out of hours message means. A tool cannot supply this and will happily let you go without it.

Write these on one page. That page is your requirement.

Example: the one-page agreement, written out. Plain sentences, one page, no policy language.

That is the whole document. Everything on it is a decision your team can make this week without buying anything.

The question before the shortlist

Ask whether the problem is a missing tool. Starting from the need rather than from the product category is the whole of the advice in the U.S. Digital Services Playbook, whose first play is to understand what people need, and starting from a shortlist quietly reverses it.

Many organizations already hold a chat capability inside a suite they pay for — Microsoft Teams inside Microsoft 365, or Google Chat inside Google Workspace — and the honest comparison is between using that properly and adding a second product such as Slack, Zoom Team Chat, or Mattermost. Adding one is defensible when the bundled option genuinely fails your agreements. It is not defensible because the bundled one is unfamiliar.

Two tools are also expensive in a way that is easy to miss: two places to look, two archives, two sets of guests, and one permanent question about where something was said.

If you end up with two, decide which is the record and which is the aside. Write that on the same page as the agreements. Otherwise you double the cost of the administrative overhead and reduce the value of both.

Four constraints that cut the field

How you work with people outside the organization. Guests inside your own account, a shared space linking two organizations, or nothing at all. These are different designs, not different price points, and the right one depends on whether outsiders are occasional visitors or people you work with every day. Get this wrong and either your partners cannot participate or they can see far more than you intended.

What you are obliged to keep, and for how long. Retention control, the ability to place something beyond deletion, and administrative export are the three capabilities that obligations turn into requirements. They also tend to sit above the entry tier, which is a pricing fact as much as a feature one.

Where accounts come from. Whether the tool draws from the directory you already run, whether joining and leaving are automatic, and what happens to someone's messages and channels when they go. A separate user list is a second thing to administer for as long as you own the product.

What must post into it. List the systems that should announce things: your ticketing system (Jira, Zendesk, ServiceNow), your deployment pipeline (GitHub Actions, GitLab CI, Jenkins), your monitoring (Datadog, PagerDuty, New Relic), your calendar (Google Calendar, Outlook). Each is a connection, and the integration surface is where the difference between candidates actually shows up.

A candidate that fails one of the four is out. This normally leaves two, at which point you can stop researching and start testing.

The population question

The requirement changes completely depending on who is in the room.

Count your organization against this table before looking at any product. Most evaluations are run by people in the first row on behalf of an organization mostly in the second, which is how a tool gets chosen that half the staff never open.

One constraint deserves testing rather than asking about, and that is the exit. A fair benchmark for what an adequate export looks like is the standard applied when a person asks for their own data. In the United States that standard is the right to data portability under the California Consumer Privacy Act, which the California Privacy Protection Agency enforces: the information has to arrive in a portable, usable form, not merely arrive. The UK Information Commissioner's Office's description of the same principle states it plainly, and it is the test to run against any candidate before you trust its export button.

Test the agreements, not the features

When you do trial something, test whether your written agreements survive contact with it.

Whatever you learn, set the conventions during the trial rather than after it. The conventions you start with are the ones you keep, which is the same lesson that governs a suite rollout and applies here with more force, because habits form faster in a chat tool than anywhere else.

Common questions

Does the free tier work?

For a small team, often, and read the retention terms first. The usual arrangement limits how much history remains visible, and the moment you discover this is the moment your history has already become the thing you would be paying to keep.

Should we let each team choose its own?

No. Communication tools only work when everyone is in the same one, and the cost of consolidating several later is far higher than the cost of deciding once.

How much should the mobile application weigh?

Heavily, unless nobody works away from a desk. For many organizations the mobile client is the product, and it is routinely evaluated last and on the newest phone in the building.

What if the honest answer is that we do not need one?

Then say so. Small teams in one place, or teams whose work is already carried by mail and a shared document store, sometimes gain nothing but interruption. The comparison discipline of asking what would have to be true for the alternative to win is worth applying to the decision to buy anything at all.