KIX

How tickets come in and get resolved: intake by email, portal, chat, phone and Microsoft Teams or Slack, incidents and service requests told apart, categories, priorities and an impact-urgency matrix, assignment rules and queues, SLAs with escalation and business hours, major incidents, templates and canned responses, a knowledge base for agents, automations and workflows, time tracking on tickets, and reports and dashboards on volume, resolution time and SLA compliance.

0 — Not a ticketing or service desk product; requests cannot be recorded and worked in it.

3 — Tickets from email and a web form with status, priority and assignment; SLAs, automation and reporting are basic or not described.

5 — Multi-channel intake (email, portal, chat or Teams), incidents and service requests told apart, assignment rules and queues, SLAs with escalation and business hours, an agent knowledge base, rule-based automations, and standard reports on volume, resolution time and SLA compliance.

8 — A visual workflow builder for any ticket type, major incident handling with communication to affected users, SLAs per service, customer and contract, skills- or load-based routing, time tracking on tickets, AI suggestions or classification with what they do stated, custom dashboards and scheduled reports, and a mobile app for agents.

10 — A service desk an organisation of thousands runs on: every workflow, form and SLA configurable without code and versioned, omnichannel intake with one history per requester, AI features documented with their data use and limits, operational level agreements and underpinning contracts tracked, and every report reproducible from an exportable ticket history.

The ITIL processes behind the ticket: problem records linked to incidents with root cause and known errors, change requests with standard, normal and emergency types, risk and impact assessment, approvals and a change advisory board, a change calendar with blackout periods, release and deployment records, links between changes, problems, incidents and configuration items, process certifications (PinkVERIFY, PeopleCert/AXELOS) named with their scope, and audit trails that a regulated buyer can show an auditor.

0 — No change or problem management of any kind; only tickets.

3 — A change or problem ticket type with a status and an approval step; change types, risk, calendar and links to incidents are basic or not described.

5 — Problem records linked to incidents with root cause and known errors, change requests with standard, normal and emergency types, multi-step approvals, a change calendar, changes linked to incidents and configuration items, and an audit trail of who approved what.

8 — Risk and impact assessment that reads affected services from the CMDB, a CAB workflow with agenda and decisions recorded, blackout periods and collision detection on the change calendar, release management with deployment tasks, change templates for standard changes, and an ITIL process certification named with the processes it covers.

10 — Change and problem management a regulated organisation can be audited on: every process configurable and versioned, change success and failure rates reported, a full trail from incident through problem and change to release exportable, the mapping to ISO/IEC 20000, ITIL 4 or DORA requirements documented, and certifications published with their scope and date.

What the product knows about the things tickets are about: an asset inventory of hardware, software and licences, a CMDB with configuration item types, attributes and relationships, a service map or dependency view, agent-based or agentless discovery, imports and synchronisation from Active Directory, Entra ID, Intune, SCCM, JAMF or a discovery tool, software licence compliance, contracts, warranties and the asset life cycle, and assets linked to users, tickets and changes.

0 — No asset or configuration data at all; tickets cannot be linked to devices or services.

3 — A list of assets with basic fields that can be linked to a ticket; relationships, discovery and licences are basic or not described.

5 — An asset inventory of hardware and software, a CMDB with configurable CI types and relationships, network discovery or an inventory agent, an import or sync from Active Directory or Entra ID, contracts and warranties per asset, and assets linked to users, tickets and changes.

8 — A visual service and dependency map used for impact analysis, discovery documented for named platforms (Windows, macOS, Linux, network devices, cloud accounts), connectors to named sources (Intune, SCCM, JAMF, VMware, AWS, Azure), software licence compliance and metering, the full asset life cycle from purchase to disposal, and data quality rules for the CMDB.

10 — A CMDB an organisation can trust for audits and outages: a documented data model with reconciliation of several sources, CI history and change tracking, service models from business service to infrastructure, licence optimisation for named vendors, and every CI and relationship exportable and reachable by API.

What employees or clients see: a self-service portal with the service catalog, request forms with fields and approvals per service, ticket status and history for the requester, a searchable knowledge base for end users, announcements and outage notices, a virtual agent or chatbot, password reset or other automated fulfilment, branding and languages, single sign-on for the portal, access from Teams or a mobile app, and satisfaction surveys.

0 — No portal or end-user access of any kind; requests can only be emailed or phoned in.

3 — A web portal where users open tickets and see their status; a catalog, knowledge base and approvals are basic or not described.

5 — A branded portal with a service catalog, request forms with approval steps, an end-user knowledge base with search, ticket status and history, announcements, single sign-on, several languages, and satisfaction surveys after resolution.

8 — A service catalog with conditional forms, costs and delivery times per item, automated fulfilment for named requests (password reset, software install, onboarding), a virtual agent in the portal and in Teams or Slack, deflection measured, portals per client or department, and accessibility (WCAG) stated.

10 — A portal that runs as the front door of the organisation: catalog, forms and fulfilment built without code and reused across IT, HR and facilities, the virtual agent documented with its sources and data use, deflection and satisfaction reported per service, and accessibility conformance published with its level.

How the product is run and connected: a cloud edition and an on-premise or open-source edition with feature parity stated, system requirements and update cadence, a documented REST API and webhooks, integrations with Microsoft 365, Teams, Entra ID, Slack, monitoring tools, RMM and remote support tools, single sign-on (SAML, OIDC) and SCIM, roles and permissions, multi-client or multi-tenant operation with separated data for MSPs, time and contract billing for MSPs, a migration path from other tools, and a public status page.

0 — No documented way to run, connect or administer the product.

3 — Runs as one edition with user roles and an email connection; the API, integrations and other editions are basic or not described.

5 — A documented REST API, integrations with Microsoft 365, Teams and Entra ID or Active Directory, single sign-on, role-based permissions, at least one monitoring or remote support integration, and either an on-premise edition or a stated hosting model with uptime terms.

8 — Cloud and on-premise or open-source editions with feature parity stated, webhooks and an integration marketplace, SCIM provisioning, multi-tenant operation with separated client data for MSPs, time and contract billing, named RMM and monitoring connectors, a documented migration from named tools, and a public status page with uptime history.

10 — Operation at scale and on the customer's terms: open-source code under a named licence or a self-hosted edition with full parity, configuration as code or a staging-to-production transport documented, an API covering every object, high availability and disaster recovery documented, and SLA and support terms published.

Who the contracting entity and the parent company are, where tickets, attachments, user directories and CMDB data are stored and processed, and who the subprocessors are (hosting, email delivery, AI features, support and payment tools). Independently sourced by the sovereignty pipeline; a service desk holds personal data about every employee and often credentials and network details, so the whole chain counts, not only the database. An on-premise or open-source edition the customer runs on its own European servers counts as the customer's chain, whatever the vendor's seat.

0 — Non-EU vendor and contracting entity, hosting unstated, subprocessors unnamed, and no data processing agreement offered.

3 — A privacy policy and a data processing agreement exist, but hosting location is unstated or non-EU and the subprocessors are not listed.

5 — EU hosting available and an EU contracting entity or EU representative, but parts of the chain (email delivery, AI features, support access, payment) run through non-EU providers without a stated safeguard, or the vendor is non-EU with an EU data centre option.

8 — EU hosting on named infrastructure, EU contracting entity, subprocessors listed with their locations, a data processing agreement published, and security certifications (ISO 27001, BSI C5, SOC 2) stated — or an on-premise edition documented that keeps every record on the customer's own servers.

10 — Sovereign end to end and evidenced: European ownership, entity, hosting and every subprocessor, or a self-hosted open-source edition with no call home, data export and deletion documented, and certifications published with their scope rather than implied.

Whether a buyer can compute the real annual cost from public pages alone: price per agent, technician or analyst and tier, whether requesters and portal users are free, what counts as an asset or node and how it is priced, which modules (CMDB, change, asset discovery, AI, ESM) cost extra, the on-premise licence or subscription and its maintenance, the free or open-source edition and paid support, minimum term, onboarding and setup.

0 — No public prices at all; every customer is a sales call.

3 — A starting price or a free edition exists, but how cost scales with agents, assets or modules is unclear.

5 — Tiers are public with their price per agent and main inclusions, but at least one commonly needed piece (asset packs, CMDB or discovery, AI features, on-premise licence, onboarding) is unpriced or "on request".

8 — Every tier priced publicly with its scaling rule (agents, assets, clients), add-ons and asset packs priced, the on-premise licence and maintenance or the open-source support plans priced, minimum term and VAT treatment stated.

10 — Complete price computability: annual cost derivable for a given number of agents, assets and modules, cloud or on premise, with every add-on, setup, training, support and overage fee and the cancellation and data-return terms published.