Case study 07 · Service operations software
Helpdesk Air
Connect requests, ownership, workflow and operational reporting.
Original conceptual diagram · No hosted tickets or private records are shown.
Make the work and its ownership visible.
A support workspace needs to show what requires attention, who owns it and how a request moves toward completion. Queues, workflow rules, service targets and reporting become more useful when they refer to the same recorded operations.
I developed Helpdesk Air to explore that connected service model: configurable workspaces and role-aware views supported by persistent data rather than a static dashboard demonstration.
Turn service rules into testable behaviour.
A custom test adapter
I built the Python/FastAPI adapter with PostgreSQL persistence and a JavaScript browser interface. The development includes configurable spaces, work queues, board/list views, request forms and workflow transitions.
Service targets and automation
The implementation includes service-target calculations, automation rules, conversation-matching logic and audit events. Workload and operational views derive from persisted records so reporting can follow the state of the work.
A distinct self-hosted foundation
I also prepared a separate deployment package using the official Zammad stack and Docker Compose. That open-source foundation retains Zammad’s authorship and AGPL licensing; it is distinct from the custom FastAPI test adapter.
Retain release evidence without turning it into a production claim.
The project includes regression checks, migration evidence, product documentation and dated acceptance records for the controlled test release. Current production rollout and external-channel activation require separate evidence.
The public case study deliberately uses a conceptual diagram. Hosted records, memberships, ticket content and integration details are outside this presentation.
A controlled test environment with clear next steps.
The deployed test adapter is a development and acceptance environment. It does not establish a production service rollout or live email/webhook delivery. The separate Zammad deployment package is a foundation rather than the engine running on the test host.
The source and operational records remain private. No customer, employee or ticket information is included in this case study, and no operational savings or service-level improvement is inferred from the implementation.