The service desk
Radd has no separate project type for a service desk. A project becomes one when you turn on the parts that fit — the table below lists them.
Every issue already carries a requester — the person who raised it. The pieces below are what an administrator turns on to run a request queue around that field.
| Setting | What it does | Default |
|---|---|---|
| SLA policies | Response and resolution timers for one project | None — no policy applies until you create one |
| Satisfaction surveys (CSAT) | Emails the requester a rating survey when their issue resolves | Off |
| Canned responses | Reusable reply text, shared by the whole server | None created |
| A mail source | Opens or updates issues from an inbox | None configured |
| A Queue view | A list built for triage, with SLA and age columns | None created |
SLA policies and satisfaction surveys are set per project, under Project settings → SLAs. Canned responses are shared by every project, under Settings → Canned responses. A mail source is server-wide, under Settings → Email, and an administrator sets it up once.
The requester is the person who raised the issue — a separate field from the assignee. It defaults to whoever created the item. Open the item, then use the Reporter field in the properties rail to change it. Anyone who can update the issue may file it on someone else's behalf this way.
A requester does not need to be able to sign in to Radd. When an issue arrives by email from an unknown address, the server creates an account for it and makes that account the requester. That account has no password and cannot sign in on its own. Email is its only way to reach the issue, until someone signs in through single sign-on with the same address and claims it. Such an account can only read the issues it reported, comment on them, and add attachments — nothing else, not even the wiki.
Radd also keeps a separate contact record for an issue raised by email: the sender's address and name, apart from the requester field itself. A customer often copies a colleague, or a colleague replies in their place. Each address that writes in becomes a contact on the issue. The first person to write is the one every other feature means by "the requester." That includes the satisfaction survey, the contact recipient in an automation, and the External requester chip on the issue.
A person merely copied in does not take over that role. An issue you create yourself, for a colleague with a Radd account, needs no contact record — the server reaches that colleague the ordinary way, through their inbox.
A request arrives. An administrator points a mailbox or a webhook at Radd under Settings → Email. A new message becomes a new issue, or a comment on an existing one:
- The server checks that the message is not a mail loop: an autoresponder, or mail from one of Radd's own addresses. It drops the message if either is true.
- It checks whether this exact message was already accepted — a retried delivery becomes one issue, not two.
- It looks for the conversation the message belongs to. First it checks
the reply headers a mail program sets, then a bracketed key in the
subject line (
[TD-412]). A subject key only threads a reply for someone already on the mail thread, the issue's requester, or any other signed-in Radd account. A stranger with no account cannot write into an issue by guessing its key. - With no match, the server opens a new issue. It first tries the
mailbox's own ordered rules: recipient address or alias, sender address
or domain, subject match, or AI classifier. If none of those match, a
plus-address in the message —
support+td@…for project TD — still routes it. With neither, the issue goes to the mailbox's default project.
A reply goes out. When someone leaves a public comment on an issue with a contact, the server emails every contact on the thread, not just the first sender. It quotes the comment under the same subject line, so it lands as a reply in their mail program.
The acknowledgement. The first time an email opens a new issue, the sender gets one receipt. It carries the issue key, a link to view it, and a reminder that replying by email adds to the ticket. This receipt answers the message, not the sender's account. A colleague signed in through SSO who emails the desk gets the same receipt a stranger does. The server sends no receipt for a missing sender address, and none back to its own mail addresses. The acknowledgement itself can never start a mail loop.
Attribution. A reply from a known, active Radd account is posted as a comment from that person, not from a generic system account. This needs them to hold permission to comment on the project. Anyone else's reply — including one from an address Radd has never seen — is posted as a system comment. It names the sender in its first line: "Email reply from jane@example.com: …".
An SLA policy sets a response target, a resolution target, or both, in minutes, for one project. Response is met by the first public comment from someone other than the requester or the automatic SYSTEM account — automated and email-loop comments never count as a response. Resolution is met when the issue first enters a state in the Done category.
A project can hold several policies. Each issue is governed by exactly one. The server checks a project's policies in order, and the first enabled policy whose priority filter matches the issue's priority wins. A policy with no priorities set matches every priority. Put a narrow policy above a broad one — Blocker in 1 hour before everything else in 8 hours. The broad policy would otherwise match first.
The clock and what pauses it. A policy's clock starts when the issue is created and pauses:
- while the issue sits in one of the policy's listed pause states (for example "Waiting for artist"),
- outside the policy's optional business hours window, if one is set,
- on a non-working day, if Count working days only is turned on — this reads the server's Working week (Settings → Time logging), which a project may override.
Breach. An unmet target that passes its deadline is Breached. A
target met after its deadline reads Met late rather than plain Met, so a
late answer is never confused with an on-time one. A policy can optionally
warn before breach: a set number of minutes before the deadline, Radd
raises an alert and fires the sla.due_soon automation trigger.
SLA chips on a list. Turn on the SLA column from a list or board's Display menu. It shows each issue's most urgent timer as a small chip:
- A countdown, such as "45m left"
- Paused
- Breached
- Met
- Met late
A Queue view (below) shows this column always, with no need to turn it on.
The SLA report. A project's Reports page has a Service desk section. It shows how many response and resolution targets were met against breached, by the week the issue was raised. Choose a window from the page — 12 weeks by default. Once satisfaction surveys are in use, the same section shows the average rating alongside.
A canned response is reply text any project member can insert into a
comment. The list is shared by the whole server — one canned response
serves every project. To read the list, you need the canned.read
permission atom, which every member holds by default. To create, change or
remove one, you need the canned.create, canned.update, or
canned.delete atom — held by administrators by default, and grantable to
any other role.
To create one:
- Open Settings → Canned responses.
- Type a title and a markdown body.
- Click Create response.
On an issue's comment composer, select Insert canned response to add one to your draft.
A canned response's body can carry variables, written as {{item.key}}. When
you insert one on an issue, each variable is replaced with a value from that
issue:
| Variable | Value |
|---|---|
{{item.key}} |
The issue's key |
{{item.title}} |
The issue's title |
{{reporter.name}} |
The requester's name |
{{reporter.email}} |
The requester's email address |
{{assignee.name}} |
The assignee's name |
{{me.name}} |
Your own name |
A variable with nothing to fill it — {{assignee.name}} on an unassigned
issue, for example — is left exactly as written. A gap in the text stays
visible, rather than turning silently blank.
The send-email automation action. Separately from canned responses, an automation rule can carry a Send email action. Its recipient is a literal address, or a role — reporter, assignee, or contact. You write its own subject and body. A role recipient that cannot be resolved — no assignee, no contact — is skipped, rather than failing the whole rule.
While someone types a title, Radd searches as they go — after three characters, with a short pause. This works on a new issue and on an intake form's submit page. A small panel lists up to five wiki pages and up to five already resolved issues that might answer the question. Each link opens in a new tab, so a half-filled form is not lost. The panel shows nothing until something matches.
Satisfaction surveys are off by default and turned on per project, on Project settings → SLAs, under After resolution.
When it is on, and the server can send mail, Radd emails the requester once. This happens the first time their issue enters a Done-category state — never again, even if the issue reopens and resolves a second time. The mail goes to the issue's contact if it has one, otherwise to the requester's own address, if that account is active.
It carries five links, one per rating from 1 (very dissatisfied) to 5 (very satisfied). Each link opens a page with no sign-in needed. The rating is already selected there, and a comment is optional. A second submission replaces an earlier rating.
The result appears as a small rating chip on the issue once the requester answers — nothing shows while it is still unanswered. The project's Service desk report section adds an average rating and a trend once responses come in.
A Queue is a view type built for triage. It uses the same view engine as a board or a list — the same query language, sharing, and quick filters. Its column set is fixed:
- Type, labels, priority, assignee
- Reporter
- Age
- SLA, always on
Create one from New view, with Type set to Queue.
A Queue orders itself by urgency: an open breach first, then the issue nearest its deadline, then the oldest issue. An explicit order in its query overrides this. Every Queue view you can see is listed together in a Queues section of the sidebar, with a live count next to each.
Mirrored from project.radd-hq.com on 2026-09-12. Documentation is written there; this copy is regenerated by scripts/publish_wiki.py and hand edits do not survive it.