Four work item types, each with its own shape
A bug, a feature ask, a change to something agreed and a client's own report are four different commitments. Certainty HelpDesk keeps them as four record types, so nobody has to call a change request a bug to get it tracked, and the request that caused the work stays attached to it.
Three things one list always gets wrong
A crash and a nice-to-have sit in the same list, so neither gets sized honestly.
By the time it is a ticket, the message that caused it has been paraphrased twice.
Records are marked done with no note, so the same question comes back next quarter.
One decision turns a report into typed work
Every request a client raises arrives unsorted, because the client is telling you what happened rather than what kind of work it is. Triage is where that becomes an issue, a feature request or a change request, and it takes about four clicks.
The client's own suggested type and priority sit on the record while you decide. They are labelled suggested, so they inform the call without making it.
- Client requests carry their own four states until they are sorted
- Issues, features, changes and tasks share seven working statuses
- An optional reason on the sort, so the same argument does not happen twice
Export button does nothing on Safari
Statuses that admit work stalls for honest reasons
Open, in progress, pending review, need meeting, rejected, cancelled and closed. A record waiting on a conversation is not the same as a record nobody has started, so both have a word.
Closing, rejecting and cancelling are the terminal three, and all three require a closing date and a closing reason. Reopening asks you to confirm first. Comments stay open for seven days after the closing date, then lock, with a line saying so.
- Four priorities: low, medium, high and urgent
- Closing date and closing reason required on any terminal status
- Delete is disabled while a record is closed
Export button does nothing on Safari
The record is converted, not copied
Sorting a request does not start a fresh ticket and leave the conversation behind. The title, description, status, priority, due date, privacy level and the reference itself all travel, and every comment and attached file is re-parented onto the new record.
Two things are stamped at the moment you confirm: your name as the person who sorted it, and your reason, which sits in the tooltip on that chip for anyone reading it later.
- Comments and attachments follow the work, so nobody repeats themselves
- Edit history and the activity trail carry across to the new record
- Where a project is connected to GitHub, a mirrored issue opens in the background
- A task or subtask that turns out to be client work can become an issue or a request, and arrives internal
A project answers for itself before you open a record
Each project holds its own request, issue, feature and change trackers, plus a task board and the maintenance agreement. Stat tiles across the top count each state and double as one-tap filters; the search box, the status and type selects and the removable filter chips narrow it from there.
The chosen tab is written into the address, so a link you paste to a colleague opens where you were. Lists page rather than scroll forever, and a thousand-item project opens as fast as a ten-item one.
- Unsorted surfaces as its own tile, so nothing waits to be noticed
- Tasks sit on a board with a column per status: drag a card to move it, and the board scrolls as you near the edge
- Search by title or by reference, from anywhere, with a keyboard shortcut
- Every dated record also appears on a calendar, finished items struck through
Request tracker · Unsorted
The project's files, and one keystroke to anything
Every project has a Files tab: upload the documents the team should be able to find in one place, save a link or write a formatted note beside them, preview or download them, and choose for each one whether it stays with the team or is shared with the client. Sharing is a deliberate step, needs the right permission and is written into the project's activity, which is the tab beside it: the project's story week by week.
Command and J, or Control and J, opens a search over the lot. Pages, including the ones somebody hid from their own sidebar; chats by name; issues, feature requests, change requests and client requests; meetings, personal tasks, organisations and projects. Results are grouped and reachable with the arrow keys.
- Clients see only the files, links and notes that were deliberately shared with them
- Attachments on an issue or a request, and on their comments, open in a preview with a Download button
- Records are found by title or by reference, from anywhere in the workspace
- The Activity tab groups by week: items changed, members added, meetings held, files shared
The things teams ask about this
Why four record types instead of one ticket with a label?
Because the four carry different commitments. An issue is something broken, a feature request is new work, a change request is a change to something already agreed, and a client request is a report that has not been triaged yet. They get their own trackers, their own tiles and their own closing rules, which is what stops a change to scope being estimated as a bug fix.
Can a record be closed without saying why?
No. Closing, rejecting and cancelling all require a closing date and a closing reason, and those two fields replace the due date, because a finished record is dated by when it finished. On an issue the reason can also record why the work existed at all, which is what the rework breakdown on the project is made of.
Does anything get lost when a request becomes an issue?
No. The record is converted rather than copied, so the title, description, status, priority, due date, privacy level and the reference stay the same, and every comment and attachment is moved onto the new record. The edit history and the activity trail come with it too, so the new record can be read all the way back to the original message.
How big can a project get before the trackers slow down?
Lists are paged on the server rather than loaded whole, so a thousand-item project opens like a ten-item one. Filters and stat tiles are applied server-side as well, so narrowing a long list is a request rather than a scroll.
Where this connects to the rest of it
See it against your own work
Thirty minutes on a call, one of your real client projects on the screen, and an honest answer about whether this part of the product earns its place in how you work.
partnerships@dhcertainty.com