Levework

From a request that lives in someone's inbox to a ticket with an enforced status, a real owner, and a record of every step.

SYSTEM / TOKENFLOW

ROLE / BUILD

STATUS / ● ACTIVE

01 / DIAGNOSE

Internal requests (IT, HR, ops, anything that isn't a customer ticket) tend to get handled over chat or email. Whoever happens to see the message picks it up, or doesn't; there's no single status, no enforced handoff, and no record of why something got sent back or rejected. Follow-through depends on someone remembering, not on the system requiring it. The original version of this workflow is live in production at a real 50–100 employee company, that deployment can't be shown here under client confidentiality. This case study is a self-built, clean-room rebuild of the same concept.

02 / DESIGN

FINDINGS

01
OWNERSHIP / Raiser can never act on their own ticket; solver = anyone with department access, not necessarily an assignee
02
WORKFLOW / Status transitions enforced server-side as an explicit map: no skipping acknowledgment straight to resolved
03
ACCOUNTABILITY / Notes required on hold/complete/revert/reject/concern; every mutation written to an activity log
04
TRUST / Frontend action buttons are a convenience mirror only, the backend re-checks and 403s regardless of what the UI shows

RECOMMENDATION

Separate 'who can act on this ticket' (department access) from 'who's assigned' (informational) so ownership isn't just a label. Enforce every status transition against a server-side map with required notes at the transitions that matter, so the history explains itself instead of relying on memory or trusting the client.

CONSIDERED AND REJECTED

Trust the frontend to only show valid actions
Rejected: the UI's action-derivation logic is a convenience mirror of the backend's rules, not the source of truth. Every action is re-validated and gated server-side regardless of what buttons the client renders.
Let a ticket move straight from pending to resolved
Rejected: skips the acknowledgment step, so nothing forces someone to actually claim the ticket before working it. The enforced transition map blocks the jump.

03 / BUILD

01 / INTAKE

02 / WORKFLOW

03 / ACCOUNTABILITY

04 / ENABLE

SYSTEM HANDBOOK

  1. 01How it works
  2. 02Raiser vs. solver roles
  3. 03Status transitions
  4. 04Departments & categories
  5. 05Admin controls
✓ DOCUMENTED✓ SELF-MAINTAINED

05 / IMPROVE

SYSTEM / TOKENFLOW

V1
flat ticket CRUD, no lifecycle
V2
raiser/solver lifecycle with enforced status transitions
V3
comments, mentions, reactions, attachments
CURRENT
admin panel, 37 backend + 22 frontend automated tests

STATUS / ● ACTIVE

This repo is still evolving. The underlying concept is already deployed and in daily use at a real company, the live version just isn't the one shown here, out of respect for that client's privacy.

Talk through a workflow like this