ZitiDesk: IT Service Management

What it is

ZitiDesk is an IT service management platform covering the ITIL essentials — incident, request, change and problem — without the licensing cost and administrative weight of a legacy ITSM suite.

It is multi-tenant: each customer's data is isolated, and each customer sees only its own catalogue, tickets and history.

Ticketing that holds up under real use

Tickets follow a full lifecycle — open, pending, resolved, closed — with automatic numbering (TKT-YYYY-NNNNNN), assignment, transfer and a complete audit trail on every change.

Comments are threaded against the ticket with the author and timestamp retained, so the history is usable months later when someone asks why a decision was made.

Attachments are supported on tickets and change requests, with size limits enforced server-side.

Roles follow the service, not the company

This is the part that most ITSM tools get wrong, and it matters commercially.

A role is bound to a service subscription, not to the tenant that owns the account. Any user can hold a role in any tenant — someone from your own team, or someone from an outside provider. A tenant can subscribe to ZitiDesk and still appoint a third-party managed service provider to run support against it.

Concretely, the same external MSP user can hold a role in several tenants at once, with each tenant's data isolated from the others. There is no distinction in the model between "internal" and "third party" — only between who holds which role, on which service.

Role	Responsibility
Tenant administrator	Manages the tenant's users, services and settings
Tenant manager	Oversees tickets and staff within the tenant
Requester	Raises tickets against subscribed services
Agent	Handles and resolves tickets — internal or third-party
Approver L1	First-line approval of a proposed change
Approver L2	Second-level approval where a change requires it
Implementer	Carries out the approved change — internal or third-party
Platform operator	Cross-tenant assistance; no tenant binding

Because the provider roles are not tied to the tenant, you can change providers without changing platform, and a provider can serve several of your tenants from one login.

Approvals and implementation are recorded against named users, which is what an audit needs to see — whoever actually performed the work, not just the organisation that owns the account.

Built for the way support actually arrives

Two-way email. Customers can reply to a ticket by email and the reply lands in the thread; agents can respond from the platform and the customer receives it as email. Nobody has to remember to log in.

Ticket routing to third parties. Work can be assigned to an external provider's users, who see only what they are entitled to and whose actions are attributed to them.

Customer self-service. A portal for raising tickets against the subscribed catalogue, checking status and reviewing history.

Per-customer service catalogue. Each customer is subscribed to the services they actually buy, so the requester picks from a relevant list rather than a generic form.

Security and isolation

Authentication supports Keycloak OIDC and a local fallback. Authorisation is enforced across the full role set with granular permissions, and customer data is separated at the query level — not filtered in the UI.

A third-party user's access is scoped to the tenants and services they hold roles on. Holding a role in one tenant grants nothing in another.

CSRF protection and hardened security headers are applied throughout, with rate limiting on authentication, single sign-on discovery and the API.

Who it suits

Organisations that need proper change control and an auditable ticket history — but do not want to fund a full enterprise ITSM deployment to get it.

It also suits the common Singapore arrangement where a tenant owns the platform relationship and an MSP or consultant delivers the support: both parties work in one system, with the separation enforced by the platform rather than by trust.