An ITIL-style service desk for Odoo that links every incident and request to the CMDB asset it affects, with impact-based SLA timers and an employee self-service portal. Built, installed, and supported by ECOSIRE after you request a quotation. Built to order by ECOSIRE for Odoo 17, 18, 19 — indicative price from $399.00 USD; request a quote for a scoped proposal.

An ITIL-style service desk for Odoo that links every incident and request to the CMDB asset it affects, with impact-based SLA timers and an employee self-service portal. Built, installed, and supported by ECOSIRE after you request a quotation.
今すぐのお支払いはありません。これはチームへの見積もり依頼を送信します。価格と次のステップをメールでご案内します。
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.
Four ITIL ticket types — incident, service request, problem, and change — each with its own state machine driven by server and automated actions
`Many2one` link from every ticket to the affected CMDB configuration item, surfacing that asset's owner, location, warranty, and full prior-ticket history inline
Impact × urgency priority matrix computed via an `@api.depends` method so ticket priority (and the applicable SLA) is derived, never hand-typed
SLA policies with separate response and resolution targets per priority tier, timers evaluated against a working-time calendar
Tiered escalation on SLA breach via `ir.cron` and automated actions — notify lead, reassign, or bump priority automatically
Technician teams with round-robin or load-balanced auto-assignment of incoming tickets
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 2–4 weeks from confirmed scope, with UAT on a staging database before go-live. Pricing starts from $399 (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.
Runs the internal help desk and wants incident management wired to real asset data — so techs see a device's full history and warranty the moment a ticket lands, instead of a generic free-text queue.
Owns SLAs and uptime commitments and needs response/resolution timers, impact-based prioritisation, and breach escalation that hold across teams, plus MTTR and SLA-compliance reporting to prove it.
Wants ITSM consolidated inside Odoo alongside the CMDB rather than a separate paid tool, with per-ticket time and cost logged for chargeback and clean reporting per asset, category, and technician.
Delivers IT support to multiple client sites and needs portal-based ticket intake, team routing, and loaner-asset tracking that map onto a shared CMDB without a generic helpdesk's blind spots.
ecosire.com でライセンスを購入し、アカウント ダッシュボードから IT Service Desk (ITSM) モジュールの ZIP をダウンロードします。
ZIP をサーバー上の Odoo カスタム アドオン フォルダーに抽出します (または、[アプリ] > [Odoo.sh / runbot のファイルからインストール] を介してアップロードします)。
開発者モードをアクティブにし、アプリを開き、「アプリリストの更新」をクリックして、「IT Service Desk (ITSM)」を検索し、「インストール」を押します。
新しいメニューを開き、ECOSIRE ライセンス キーを貼り付け、外部認証情報 (Shopify、Amazon、Stripe など) を接続して保存します。
組み込みの接続テストを実行し、最初の 10 レコードを同期し、定期的な cron をスケジュールします。何か問題が発生した場合はサポートにお問い合わせください。
| 基準 | エコシエール | カスタムビルド | 競合他社 | オドゥー ネイティブ |
|---|---|---|---|---|
| Link between ticket and hardware asset | Direct CMDB link on every ticket with full asset history inline | Possible but you build and maintain the relation yourself | Usually free-text or a loose reference, not a real CMDB link | |
| Priority from impact × urgency | Computed automatically from a configurable matrix | Must be designed and coded from scratch | Often a flat priority field, no matrix | |
| SLA timers and breach escalation | Response/resolution timers on a working calendar with tiered escalation | Build the cron, timers, and escalation logic yourself | Basic SLA on some, limited escalation | |
| Employee self-service portal | Portal scoped to raise and track hardware issues with suggested articles | Custom portal templates to design and secure | Generic portal, not asset-aware | |
| ITIL ticket types (incident/request/problem/change) | All four with distinct workflows | Whatever you scope and build | Often incident/request only | |
| Auto-created tickets from monitoring/warranty | Webhook and schedule-driven creation via JSON/XML-RPC | Integrations built per source | Rarely included | |
| Chargeback (time & cost per ticket) | Time and cost logged per ticket with reporting | Add and report on it yourself | Partial time tracking at best | |
| Ownership and lock-in | Full source and git handover, yours to extend | You own it but carry all build cost and risk | Vendor-controlled, proprietary |
This is a build-to-order module, so nothing ships off a shelf. After a scoping call to confirm ticket types, your SLA matrix, escalation rules, and CMDB fields, typical delivery is 2–4 weeks from confirmed scope, including UAT on a staging database before go-live. Larger scope — multi-company, heavy integrations, or historical-ticket migration — extends that timeline, which we state in the quote.
Yes. The whole point is linking tickets to real configuration items, so it builds on the CMDB asset module along with `base`, `mail`, `portal`, and `hr`. If you do not yet run a CMDB in Odoo, we scope that setup into the engagement so tickets have real assets to reference from day one.
Pricing starts from $399 as an indicative figure for a single-company base scope. It is not a fixed price — after the scoping call we confirm exactly what you need and issue a firm fixed quote. Drivers like multi-company routing, monitoring/webhook integrations, complex SLA calendars, or large data migrations increase the quoted scope.
Every build includes a post-go-live support window for defect fixes and configuration tweaks, plus a git repository handover so the code is yours. Beyond that window we offer ongoing support and version-upgrade retainers; because you receive the full source, you are never locked in.
We build against Odoo 17.0, 18.0, or 19.0, on either Community or Enterprise. We confirm your exact version and edition during scoping and develop and test against that target, since model and view APIs differ between releases.
Yes. We wire auto-creation from warranty and maintenance schedules and from external monitoring tools via the JSON-RPC/XML-RPC API, so an alert or a due maintenance date opens a ticket with the correct asset, type, and priority already attached.
Each priority tier maps to an SLA policy with response and resolution targets measured against a working-time calendar. Timers compute remaining time, and on breach a scheduled action fires tiered escalation — notifying the team lead, reassigning, or raising priority — so nothing silently ages out of target.
An ITIL-style service desk for Odoo that links every incident and request to the CMDB asset it affects, with impact-based SLA timers and an employee self-service portal. Built, installed, and supported by ECOSIRE after you request a quotation.