Most IT teams running Odoo end up bolting incidents onto a generic ticketing tool that has no idea what a laptop, switch, or server actually is. A ticket lands and the technician has to go hunting: which machine is this, who owns it, what is its warranty status, was it touched last week for the same fault? Odoo core gives you mail, activities, and a discuss thread; the proprietary Enterprise helpdesk gives you a ticket object — but neither knows your hardware. There is no native link from a ticket to a configuration item, no impact-and-urgency matrix, no SLA clock that starts on submission and escalates on breach, and no self-service portal scoped to "raise a hardware issue." This is exactly where the native road runs out, and where a typical off-the-shelf apps.odoo.com module still treats your assets as free text.

We build an ITIL-aligned service desk as a proper Odoo application on top of base, mail, portal, hr, and your CMDB (it_asset_management_cmdb). At the core is a ticket model (models.Model) supporting four ITIL ticket types — incident, service request, problem, and change — each with its own state machine driven by server and automated actions. Every ticket carries a Many2one to the affected configuration item, so opening a ticket surfaces that asset's full history — prior tickets, owner, location, warranty, and maintenance schedule — pulled straight from the CMDB with no re-keying. Priority is not typed by hand: a compute method with @api.depends('impact_id', 'urgency_id') reads an impact × urgency matrix and derives ticket priority automatically, which in turn selects the applicable SLA policy.

SLA policies attach response and resolution targets to each priority tier, with timers that compute elapsed and remaining time against a working-calendar and fire tiered escalations on breach via ir.cron and automated actions (notify lead, reassign, bump priority). Technician teams support round-robin or load-balanced auto-assignment. An employee self-service portal built on portal and QWeb lets staff raise and track hardware issues, see status, and read suggested knowledge-base articles linked to the ticket category. Tickets can be auto-created from warranty and maintenance schedules or from monitoring webhooks over the JSON-RPC/XML-RPC API; loaner or replacement assets can be tracked against the CMDB while a device is in repair; and time and cost are logged per ticket for internal chargeback. Access is locked down with ir.model.access.csv plus record rules so technicians, team leads, and portal users each see only what they should. Reporting covers MTTR, SLA compliance, and tickets per asset, category, and technician, delivered as Odoo pivots, dashboards, and QWeb PDF reports.

Because this is build-to-order, nothing ships until we agree scope. After you request a quotation we run a short scoping call, confirm your ticket types, SLA matrix, escalation rules, and CMDB fields, then build against your target Odoo version (17.0, 18.0, or 19.0, Community or Enterprise). Typical delivery is one working week from confirmed scope, with UAT on a staging database before go-live. Pricing starts from $999 (indicative, single-company base scope); multi-company routing, deeper monitoring/webhook integrations, complex SLA calendars, or migrating a large volume of historical tickets increases the quoted scope.