← All postsHow-to

Channel naming convention: making a chat workspace searchable

A channel naming convention decides whether people find the right conversation or start a fifth one about the same thing. A scheme that survives growth, and what to do with the mess you already have.

How-toC

A chat workspace stops being useful at roughly the point where nobody can guess what a channel is called. People then do the rational thing: they start a new one. A channel naming convention is the cheap fix, and it is worth agreeing while you have forty channels rather than four hundred, because renaming later breaks every link anybody ever pasted.

What a channel naming convention needs

  • A prefix that says what kind of channel it is — team, project, customer, incident, social — so an alphabetical list groups itself.
  • A consistent separator and case. Pick hyphens and lower case and stop thinking about it.
  • Names that read as nouns, not sentences. A channel called "discussing-the-migration" ages badly the week the migration ends.
  • No personal names in shared channels. People leave; the work does not.
  • A length people will actually type, which in practice means under about thirty characters.

A scheme that survives growth

Four prefixes cover almost everything: team- for standing groups, proj- for anything with an end date, cust- for external or client-specific work, and inc- for incidents. Everything else goes without a prefix and is social by default. The discipline that matters more than the scheme is the end date: a proj- channel gets archived when the project closes, which is what keeps the list from accumulating the sediment of every initiative since the company started.

Write the convention into the channel-creation moment, not into a wiki page. A one-line description visible when somebody is about to create a channel changes behaviour; a policy document does not.

Fixing a workspace that already sprawled

  1. List channels by last message date — the dead ones are the easy half of the problem.
  2. Archive rather than delete: history stays searchable and the name stops appearing in autocomplete.
  3. Merge duplicates deliberately, announcing it in both, and pin a pointer in the one you are closing.
  4. Rename only where the gain is large, because renaming breaks existing links.
  5. Give every surviving channel a one-line purpose in its description — the test of a good name is that the description is almost redundant.
  6. Set a review date and do it twice a year; without that the sprawl simply restarts.

What naming cannot fix

If decisions live only in chat, no naming scheme will make them findable a year later — search returns the conversation, not the conclusion. The convention is for routing attention; decisions, owners and dates belong somewhere structured. The practical rule is that anything you would be annoyed to lose should leave the channel the day it is agreed.

Ettex Chat keeps channels with descriptions and an archive state rather than deletion, so a closed project stops appearing in autocomplete while its history remains searchable. Decisions that come out of a channel belong in a record alongside, which is what makes them answerable without re-reading a thread.

Frequently asked

Should channels be public or private by default?

Public, with private reserved for genuine confidentiality. Private-by-default recreates the email problem it was meant to solve: information exists but nobody can find it.

Is it worth renaming existing channels?

Only where the confusion is real. Renaming breaks pasted links, so archive-and-replace is often cleaner than rename.

How many channels is too many?

When people start new ones because they cannot find the existing one. That is the symptom to watch rather than any particular number.

MI
Written by Maria I.

Part of the Ettex team — writing about product, engineering and the future of work.

More posts
Get the best of the Ettex blogProduct news, guides and tips — straight to your inbox, no spam.