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.

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.

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. You triage it: set an owner and priority, add internal notes, and do the work.
3. You send a Reply to customer → they receive it as an email and can simply reply.
4. Their reply lands back on the same ticket as a new customer comment, and notifies your team.
5. 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.