Proposed UI changes
A walkthrough of suggested improvements to the in-house ticketing system. Each section shows the proposed design. It's interactive, so you can click through it, with notes on the reasoning.
Category → multi-select color tags
Replace the single-select Category dropdown with color-coded tags that support selecting more than one. The field is typable, so you filter the list as you type, plus an inline “add new” that picks the next unused color. Collapsed into a dropdown so the form stays compact as the taxonomy grows.
Type to filter, click to toggle, or add a new one.
Why change it
- A ticket often spans more than one area, so multi-select captures that instead of forcing one bucket.
- Typing to filter keeps it fast once the list of categories gets long.
- Color makes categories scannable at a glance in the ticket list, not just in this form.
Assign to me, with undo and reassign
Waiting tickets get a one-click button that claims the ticket and moves it to In progress with you as the assignee. Right after claiming, the button becomes Undo in case it was a misclick. Tickets that already have an owner show a Reassign action, handy when filtering by Assigned.
| ID | Category | Issue | Priority | Status | Assignee | Actions |
|---|
Why change it
- Claiming a waiting ticket today means opening it first; this removes that step.
- Undo right after claiming covers the inevitable misclick without a trip to the record.
- Reassign lets a lead hand a ticket to the right person without losing the owner trail.
Overriding an account lockout: drawing the line
Accounts lock on too many login attempts or on detected suspicious activity. Legitimate users do get locked out by mistake and will call in, so support needs a way to help, without that path becoming the easiest way for an attacker to get in. This section is the proposed policy, not a screen.
Core principle: separate clearing the lock from regaining access. An agent can clear the lock, but the caller must still prove possession of something pre-registered to actually get in, and any new credential goes to the owner, not the caller. That way a socially-engineered agent still doesn't hand over the account.
The real risk here isn't the lock itself; it's an attacker phoning support, impersonating the owner, and talking a helpful agent into opening the door. Every decision below is aimed at that, while keeping the honest-mistake path quick.
The backend already records the lockout reason, so we can route the two cases differently instead of treating every unlock at the strictest bar.
| Lockout cause | Risk | Proposed handling |
|---|---|---|
| Too many login attempts | Low | Usually a real fat-finger. Light identity check, clear the attempt counter, force a password reset on next login. |
| Suspicious activity detected | High | May be an active attack. Stronger verification, supervisor approval, mandatory credential rotation, owner notified, sensitive actions frozen. |
Before clearing a lock, the agent sends a one-time PIN to the email on the account and has the caller read it back. Simple, uses a channel we already have, and a bad actor calling in can't receive it.
- One-time PIN by email chosen approach
A short code is emailed to the registered address; the caller reads it back to confirm control of the account before the lock is cleared.
Guardrails on the override
- Full, tamper-evident audit trail: who, when, method used, reason.
Open questions
- Confirm every account has a verified email on file, and decide the fallback when it doesn't.
Ticket number format: adding headroom
Today's IDs are T20260001: a T, the year, and a 4-digit counter that resets yearly, capping the system at 9,999 tickets per year. We're moving to a month-based format with far more headroom.
New format: T26010001, where T is the prefix, 26 is the year, 01 is the month, then a 4-digit counter that resets each month. That allows 9,999 tickets per month, and the ID itself tells you when the ticket was opened.
Why this format
- 9,999 tickets per month is far more headroom than the old 9,999 per year.
- Year and month are embedded, so the ID hints at when a ticket was opened.
- Still short and easy to read aloud over the phone.
Decisions to lock in
- Counter resets at the start of each month; keep the width fixed at 4 digits and zero-padded.
- Decide whether existing
T2026xxxxIDs are reformatted or left as-is. - Check anywhere IDs are parsed or stored downstream (exports, integrations).
Internal vs. external messages: an unmistakable toggle
One composer with a real toggle between an internal note and a customer reply, where the two modes look completely different (pane colour, border, text colour, and send button), so an internal message can't be sent externally by accident. The same colour convention runs through the thread, so you can see at a glance which past messages went to the customer.
Refreshed ticket statuses
Add an On hold status for tickets paused on the customer or something else, and a Closed status for tickets finished without a resolution (duplicates, can't-reproduce, out of scope). Refresh the status colours for clarity, drop the Assigned status, and rename Open to In progress. Each status keeps its own filter bubble.
Why change it
- “Waiting” lumped queued tickets with ones parked on a customer; On hold separates them.
- Closed captures tickets finished without a fix (duplicates, can't-reproduce) so they don't masquerade as Resolved.
- A clearer colour scheme (blue working, yellow waiting, red on hold, green resolved, grey closed) makes status scannable at a glance.
Decisions to lock in
- Does putting a ticket On hold pause any SLA / response-time clock?
- Confirm the term “Closed” and when agents use it instead of Resolved.
- Confirm the Open to In progress rename propagates (filters, reports, exports).
Preview logs without downloading
Add a Preview action next to Download in the device logs list. It opens the log in a modal with the full file, colour-coded by level and searchable, so an agent can eyeball what went wrong during a call instead of downloading, opening, and discarding a file.
Troubleshooting as a guided chatbot
Reframe the decision tree as a floating chat assistant: a launcher button opens it over any page, and it asks one question at a time with quick-reply buttons instead of a wall of boxes. Author-defined branches keep it accurate; it's the look and flow that change, ending in either a fix or a hand-off to create a ticket. The tree here is illustrative.
Why change it
- One question at a time is far less overwhelming than a page of branching boxes.
- A floating launcher means help is reachable from anywhere, not just this article.
- Guided buttons keep answers accurate, with no AI guesswork, and dead-ends route straight to a ticket.
- Nice-to-have: page-aware context, so opening it on the water-sensor article starts with water-sensor troubleshooting.
Article publishing & version history
Give KB articles a proper authoring lifecycle: a “published by” byline, an Edit mode with Save as draft / Publish, and a version history you can roll back to. Rollback restores as a new version so nothing is lost.
Publishing articles to a public, customer-facing site is deferred for now; we'll wait for customer data and feedback before building a public knowledge base.
Why change it
- “Published by” plus status makes ownership and state clear at a glance.
- Draft / Publish separates work-in-progress from what staff rely on.
- Version history with rollback means a bad edit is never permanent.
Admin center: users & roles
An admin area styled like the profile page: a user list with create, edit, reset password, and role assignment, plus role management. New users are created with a password the admin sets and shares, to be changed at first login. Admin and Helpdesk are built-in roles; you can add custom roles with their own permissions.
Why add it
- User and role management currently has no home; this gives it one, in the existing visual style.
- Admins set an initial password and share it; users change it at first login.
- Built-in Admin/Helpdesk cover the common case; custom roles scale later without exposing the core two to mistakes.
My queue: your unresolved tickets
A My queue item near the top of the sidebar that collects every unresolved ticket assigned to you, with a live count badge. Sorted by status, then date, so the most neglected work surfaces. One place to see what's yours without filtering the full list each time.
Why add it
- Agents shouldn't have to re-filter the full ticket list to find their own open work.
- The count badge gives an at-a-glance sense of personal workload.
- Sorting by status then date keeps the longest-neglected tickets from slipping.