Working a Ticket

This is the heart of Service Desk: the moment-to-moment work of reading a request, talking to the customer, and getting it done. Because a ticket is an ordinary work item, everything you already do with items — assign an owner, set a priority, move it across a board, add it to a cycle — works here too. What's new is the conversation.

Triage from the Inbox

Open Service Desk → Inbox for your triage queue. It's the familiar items table, automatically scoped to tickets — a locked Tickets only filter keeps non-support work out, so you're always looking at customer requests and nothing else.

From here you can:

• Sort and scan new requests, and open one to start working it.
• Select several at once (click, ⌘/Ctrl-click, or Shift-click a range) to update them in bulk — reassign, re-prioritize, or move them together.
• Switch to a saved view such as Unassigned to focus on what still needs an owner, or save your own.

Automatic priority from incoming email

When a new ticket arrives by email, DevStride reads the subject and message and chooses the closest match from the priorities configured for that ticket's work type. A message such as “URGENT: production is down” can therefore arrive already elevated, while a routine request stays at the configured default.

The classifier only runs while the ticket still has its default priority. A priority supplied by a request form or already set by a team member is never overwritten. If the AI service is temporarily unavailable, DevStride falls back to a conservative urgency-word check using the priorities your organization actually configured; it never invents a new priority.

Prioritizing with Customer Importance

Beyond the standard priority, tickets carry a Customer Importance — a quick triage signal for how much a request matters to the customer:

• Critical — high-stakes work that should jump the queue.
• Important — matters, but not on fire.
• Nice to have — low-urgency requests.

Set it right on the ticket while you triage, or select several tickets in the Inbox and set their importance in bulk in one action. Customer Importance is more than a label: you can sort and filter on it (see Finding & Filtering Tickets) and match SLA policies against it (see SLAs), so it feeds directly into how tickets are surfaced and how their deadlines are set.

Merging duplicate tickets

When the same issue comes in twice — a customer emails and also fills in a form, or two people report the same outage — you can fold the duplicates into one. Open the ticket menu and choose Merge, then pick which ticket survives. The other ticket's conversation and history move onto the survivor, so you're left with a single thread instead of scattered fragments, and future replies all land in one place.

The two descriptions: Internal and Customer

Open a ticket and you'll see its description split into two tabs:

• Customer — what the requester wrote, and what they can see. The body of their original email lands here.
• Internal — your team's working description, private to the organization.

Keeping the customer's words and your team's notes apart means you can capture internal context — reproduction steps, links to related work, a blunt assessment — without ever exposing it to the customer.

If the original email included files, an Attachment indicator and the linked filenames appear directly beneath the Customer description. Attachments on later inbound replies appear beneath the exact customer comment or nested reply that included them. Selecting a filename opens the saved file; the same attachments remain available together from the ticket's Assets tab.

Replying: customer replies vs. internal notes

Every ticket has one conversation thread, but each entry is one of two kinds. The composer lets you choose before you send:

When you send a Reply to customer, DevStride emails it to the requester and threads it so their response comes back to the same ticket. An Internal note never leaves DevStride.

How the conversation flows

1. A customer emails your support address → a ticket appears in the Inbox with their message as the Customer description.
2. DevStride makes an initial priority choice from the email when the ticket still has its default priority.
3. You triage it: confirm the priority, set an owner, add internal notes, and do the work.
4. You send a Reply to customer → they receive it as an email and can simply reply.
5. Their reply lands back on the same ticket as a new customer comment, notifies your team, and shows any attached files alongside that message.
6. When it's resolved, you move the ticket to a closed status like any item.

Who can reply to customers

Anyone working the ticket can add Internal notes, but sending a Reply to customer requires the Send Public Replies permission. This lets you bring in collaborators — say an engineer investigating a bug — who can contribute internal context without the ability to message the customer directly. See Permissions.