Team chat: what it has to do before it saves anyone time

Team chat — teamchat, internal messaging, whatever the tool is called — has replaced internal email almost everywhere, and the replacement is genuinely better for the things chat is good at. It is also the reason a lot of people describe their working day as interrupted. The software did not cause that. The absence of any agreement about how to use it did.

The useful question is not which tool to buy. It is what has to be true about how a team uses chat before it saves more time than it consumes.

What team chat is good at, and what it is not

• Good: short exchanges that would have been three emails, quick questions with a fast answer, coordination during something live, informal contact in a remote team.
• Good: keeping a running record of a project in one place people can search.
• Bad: decisions that need to be found again in six months. Chat is searchable in theory and unfindable in practice.
• Bad: anything long or carefully argued. A proposal in a chat message gets skimmed and answered in fragments.
• Bad: work that needs an owner and a due date. That is a task, and a message is not one.
• Bad: anything a person outside the channel needs, which is most things eventually.

The recurring pattern behind almost every complaint about team chat is the same: something that needed to be a document or a task was posted as a message, and everyone then spent a week treating a scrolling log as though it were a record.

Channels beat direct messages

The single most useful convention is to default to a channel and treat direct messages as the exception. Work discussed in DMs is invisible: colleagues cannot learn from it, cannot pick it up when someone is away, and cannot see that it happened. Every DM about work is a small private silo, and a team of eight generates a lot of them.

This is also why channels should be organised by topic rather than by team. A channel per project is joinable by anyone who needs context; a channel per department forces cross-team conversation back into DMs.

Expectations about response time

Chat looks synchronous and mostly is not, and the mismatch is where the interruption comes from. If nobody has said what a normal response time is, everyone assumes it is immediate and behaves accordingly — checking constantly, and treating a two-hour silence as being ignored.

1. Agree a default response window in writing. A few hours is realistic in most teams.
2. Agree how genuine urgency is signalled, and make it something other than chat — a call, usually.
3. Say that notifications off during focused work is expected rather than tolerated.
4. Use threads for replies, so a channel stays one conversation deep.
5. Write the outcome of any consequential discussion into a document, and link it.
6. Turn anything with an owner and a deadline into a task rather than a message.
7. Review channels quarterly and archive the dead ones.

The record problem

Chat search works well when you remember roughly what was said and roughly when. It works badly for the question people actually ask, which is why did we decide this. The decision is usually spread across nine messages, two of which contain the reasoning, and the thread that contains them was in a channel that has since been renamed.

The fix is a habit rather than a feature: when a discussion concludes something, someone writes a short note of what was decided and why, in a document, and posts the link. Ninety seconds of work, and it converts a conversation into something a new colleague can read in a year.

Where it sits alongside everything else

Ettex Chat is built for that division of labour rather than against it — channels per project, threads, and the assumption that the durable version of anything lives in a document or a task and chat links to it. It sits next to the documents, files and boards the same team already uses, so moving a conclusion out of a thread does not mean moving it into a different company product.

To be clear about the boundaries: it is text and file sharing between people in a workspace. There is no voice or video calling, no telephony, and no customer-facing support widget — for a live conversation, chat is the wrong tool anyway, and for customers a support address serves them better than an internal channel they cannot see.

What makes it worse

• No agreed response time, so everyone assumes immediate.
• Work happening in direct messages, invisible and impossible to hand over.
• Channels by department instead of by project.
• Replies posted in the channel rather than in threads, so three conversations interleave.
• Decisions left in the log and never written down anywhere findable.
• Notifications on for everything, which trains people to ignore all of them.
• Channels created for every occasion and never archived.

Chat is one channel among several, and the decision that matters is which conversations do not belong in it. Anything that has to be findable in a year — a decision, a commitment, a policy — belongs in a document or a record instead. The wider question of which internal communication tools carry which traffic is worth settling once, in writing, rather than per team.

Team chat is worth what your conventions make it. Default to channels, agree a response time, thread the replies, and move every decision out of the log and into a document.