Keeping clients told
Somebody outside the company is waiting for a piece of work. They do not want an account, a login or a board — they want to know when it starts and when it lands.
A subscriber is that person. They follow a project, an epic or an issue, and hear exactly twice.
Adding one
On an issue, epic or project: told about this in the properties panel. An email address, optionally a name, and Add.
They receive nothing at that moment. Subscribing is not an event worth an email — the work has not moved.
A subscriber is deliberately not a user. Giving a client an account would put them in the member list and in every "who can see this?" question from then on, forever. This way they are an address and nothing more.
What they hear, and when
Twice:
| When | Trigger |
|---|---|
| Work starts | The issue enters a status in the started category |
| Work lands | It enters a status in the completed category |
The trigger is the category, never the name. Rename
in progress to Building and the client's mail still arrives — the one place this could
have gone wrong is the place it must not.
An issue that moves back and forth does not send twice. They hear the first time it starts and the first time it finishes.
The one sentence they read
Every issue has two pieces of text, and only one of them ever leaves the building.
| Written for | Sent | |
|---|---|---|
| Description | Colleagues | Never |
| What to tell people outside | A stranger | Yes |
The description is where somebody writes "the auth thing Astrid broke last sprint, probably the session regeneration again". It is honest, useful, and not for a client. So it is never sent, and never used as a fallback either — an issue with no external note sends the title and nothing else.
That field is a plain text box on purpose, not a rich editor. It is one sentence for a stranger, not a document.
Write it when you file the issue. The moment work starts is the wrong moment to discover the only sentence a client will read has not been written, and the mail goes out with just a title.
What the mail looks like
The issue's title, your external note, why it arrived, and a one-click unsubscribe — the button Gmail and Outlook show at the top of a message, not a link buried at the bottom.
It is branded with your installation's name. A client of Inside NEXT Works receives mail from Inside NEXT Works and never learns the software underneath is called something else.
Unsubscribing
One click, no confirmation screen, no login. Somebody who has unsubscribed is shown as such on the issue rather than hidden, so nobody adds them again next week wondering why they never reply.
They stay unsubscribed across everything they followed. A client who has had enough has had enough.
Epics are usually the right level
An issue is often too small to be interesting outside — a client rarely wants to hear
that INF-47 Add index on sessions.user_id has started.
An epic is the unit somebody outside actually asks about, and the Epics page shows how many subscribers each has. That number is worth watching: it means somebody is waiting for this who cannot see your board.
What this is not
- Not a portal. There is nothing for them to log in to, by design.
- Not a status feed. Two messages, not a running commentary.
- Not a comment thread. A reply to the mail does not reach the issue; a comment on the issue does not reach them.
If a client needs more than this, they need a person, not a notification.
Related
- Email — how mail is sent, and what to configure
- Working with epics — the level most subscribers belong at