Team Rooms: Focused Spaces for Projects and Incidents
When a ticket is the wrong shape for the work — a launch, an incident, a short project — give the group a private room with chat, a deadline and a way to get attention. How rooms work and when to use them.
Team project rooms are small, private spaces where the handful of people working on one thing — a launch, an incident, a two-week project — chat live, share a deadline and pull each other in when something needs attention. They sit between a ticket (one request, one owner, one deadline) and a company chat channel (everyone, forever). Use a room when the work is collaborative and time-boxed, keep membership invite-only and enforced by the database, and close it when the work is done.
When a ticket isn't the right shape
A request desk is built for discrete asks: someone needs something, a team owns it, there's a target time. Some work doesn't fit:
- An incident. Five people from three teams need to talk continuously for an hour.
- A launch. A marketing, product and support group coordinating over two weeks.
- A small project. A task list, a deadline, a lot of short questions.
Forcing this into the ticket queue floods it with comments nobody else needs. Forcing it into a big chat channel mixes it with everything else and exposes it to people who don't need to see it. A room gives the work its own boundary.
What a room contains
| Part | Why it matters |
|---|---|
| Members | Only the people doing the work — invite-only |
| Live chat | The back-and-forth, with mentions that notify |
| A deadline | Everyone sees the same countdown |
| Shared items | Links, decisions, files that belong to this work |
| An attention "ring" | A deliberate way to pull members in now |
In LetRelay, rooms are free: create one, set a deadline if relevant, add members, and chat in real time. Room owners manage membership and the deadline.
The ring: attention on purpose
Chat has a notification problem: either everything notifies (and people mute it) or nothing does (and urgent messages sit unread). A room's ring is a deliberate, rare signal — "I need everyone's eyes on this now" — separate from ordinary messages. Used sparingly, it keeps its meaning. It's the room equivalent of a page in an on-call rotation, and Google's SRE guidance on on-call applies: pages should be rare, actionable and worth waking up for, or people stop responding to them.
Privacy that's actually private
Rooms are often where early or sensitive work happens: an incident's first theories, a reorganization, a product not yet announced. Privacy has to be real:
- Only members can see the room exists, let alone its messages.
- Membership is enforced in the database with row-level security, not by hiding it in the UI.
- Removing a member removes access immediately, including to history.
Enforcing this on the server is what makes people comfortable using rooms at all. The model is the same as the rest of LetRelay's security: see row-level security vs app-layer authorization.
Realtime, with a caveat
A room's value is momentum, so messages should appear instantly. Supabase Realtime offers two relevant features:
- Postgres Changes streams inserted rows to subscribers, filtered by row-level security.
- Broadcast sends messages to everyone on a channel directly, without going through the database's change stream.
For membership-gated content, LetRelay uses broadcast: after a message is saved (through the normal, permission-checked path), the sender's client broadcasts it to the room's channel, and members' clients show it immediately. The database remains the source of truth — if a live message is missed on a flaky connection, a refresh loads it from storage. Messages are never lost, only occasionally delayed.
Retention
Chat accumulates. For a free database tier with a 500 MB limit, unlimited chat history is a slow-motion problem. LetRelay keeps room chat for 60 days on the Free plan and unlimited on Pro, and deletes old messages with a scheduled database job. Whatever your rule, make it explicit: people should know how long room history lasts, and anything worth keeping — a decision, a postmortem — should be written somewhere durable before the room closes.
A room's lifecycle
- Open with a clear name ("Incident — login failures 24 Sep", "Launch — Q4 pricing page") and a deadline if there is one.
- Invite only the people doing the work. Others can be added when needed.
- Work — chat, tasks, ring when it matters.
- Close — write the outcome (what was decided, what's left, who owns follow-ups), turn follow-ups into tasks or requests, and archive the room.
For incidents in particular, the close step is the postmortem: what happened, why, and what changes. Atlassian's incident-management guides describe the same pattern: a dedicated space during the incident, and a written review after.
A worked example: an incident in a room
09:12 — Several people report that sign-in fails. The IT on-call opens a room, "Incident — sign-in failures 24 Sep", sets a deadline of 11:00 for a fix or a workaround, and invites the identity engineer, a support lead and the IT manager.
09:15 — The on-call rings the room. Everyone joins. The first message sets roles: who investigates, who communicates with staff, who decides.
09:20 — The support lead posts one status update in the company channel, pointing people to a single request in the desk for updates rather than to the room. The room stays for the people fixing it; everyone else gets status from the request.
09:40 — The cause is found: an expired certificate on the sign-in provider's integration. The fix is scheduled; a workaround (a backup sign-in method) is shared.
10:05 — Resolved. The on-call writes the outcome at the top of the room: cause, fix, time to resolve, and three follow-ups. Each follow-up becomes a task with an owner: automate certificate expiry alerts, document the backup sign-in, review who gets paged.
Next day — A short postmortem, written from the room's history, is saved to the knowledge base. The room is archived.
The room kept the noisy, fast conversation in one private place; the request desk carried the public status; tasks carried the follow-ups. Each tool did the job it's shaped for.
Rooms vs channels vs tickets
| Ticket | Room | Chat channel | |
|---|---|---|---|
| Audience | Requester + owning team | Invited members | Anyone who joins |
| Lifetime | Until resolved | Days to weeks | Indefinite |
| Structure | Status, owner, SLA | Deadline, members, chat | None |
| Best for | One ask, one owner | Time-boxed group work | Ongoing, open discussion |
If you find a room lasting months, it's probably a team, not a project. If a room has one person asking and another answering, it's a ticket — file it in the request desk. For scheduled conversations rather than continuous ones, book a meeting.
FAQ
What is a team room?
A private, time-boxed space for a small group working on one thing, with live chat, a shared deadline and a way to call members' attention.
When should I use a room instead of a ticket?
When several people need to collaborate continuously on something with a start and an end — an incident, a launch, a short project. Single requests with one owner belong in tickets.
Are rooms private?
They should be, enforced by the database: only members can see a room, its messages and its members.
How long is room chat kept?
It depends on the tool and plan. In LetRelay, room chat is kept for 60 days on the Free plan and without a limit on Pro. Record decisions somewhere durable before a room closes.
Sources
Building Relay — the internal request desk with AI triage and SLA tracking.
Run your internal requests on LetRelay
AI triage, SLA-tracked queues, and bottleneck analytics — the help desk your team actually likes. Free to start.
Keep reading
Internal Help Desk Satisfaction Surveys That Tell You Something
How to measure satisfaction with an internal help desk without annoying everyone — one question after resolution, a follow-up only on bad scores, response rates, CSAT vs effort vs NPS, and turning answers into changes.
LLM Tool Calling for Internal Assistants: Design Choices
How to give an internal AI assistant tools — reading workspace data with the user's permissions, formatting results for the model, native function calling vs a routing step, limits on how many tools run, and answers that stay inside the data.
Facilities Request Management: From Broken Chairs to Keys
How to run facilities requests like a proper service — categories, location on every request, safety issues that skip the queue, vendor work, recurring maintenance and the numbers that show where the building needs attention.