After putting a multi-client contact center's infrastructure back in order, the most delicate step: replacing the ticketing system. A program born in 2008, grown by accretion, with over three million tickets and a configuration impossible to govern without the vendor. We rebuilt it on Odoo Community — but first we looked at what is actually used.
01Before designing: look at what's actually used
The first document wasn't a project: it was an analysis of real usage, querying the database. The numbers changed the priorities: 93% of tickets aren't opened by a person but by the phone system, on call arrival — the phone integration is the heart, not an add-on. Of the six thousand reasons configured, only a few hundred were used last year. Almost one ticket in three was attributed to no client. Five statuses had never been used. Hence the principle: reproduce the core that's used, well, and leave the rest behind.
02The core choices
All open source, no licenses: Odoo Community with the OCA community helpdesk modules, on an on-site server — no fees, no data outside the company. Login with the domain account. Strict per-client separation: each client company sees only its own tickets and customers. Configurable by those who use it: statuses, reasons, texts and wiki are managed by the team leads — the more the system adapts itself, the less development is needed.
03What we built
A ticket card designed for the phone: it follows the call sequence, the most-used reasons come first, repeated phrases became one-click quick texts. A change history with legal weight: every field enters the log with previous value, author and time; tickets and notes aren't deleted, they're corrected by adding. Direct connectors to the clients' databases: you search a customer by code, name or supply and the record enters the ticket, without going through an external service.
04REST API and wiki inside the ticket
The new system exposes a documented REST API (OpenAPI) with separate keys per external system, per-client permissions, signed webhooks. And the knowledge base — over three thousand articles — was reordered and brought inside the ticket card: it shows the articles for the client and the reason being handled, searchable by a word, opened right there. The goal was one: operators shouldn't have to open ten windows to answer a customer.
05Data: populate before validating
A new system is validated with real data. We imported the whole current year — about 175,000 tickets and nearly 80,000 records — with original dates, multiple reasons and references. The full import takes fifteen minutes and is repeatable: it only adds what's missing. It also surfaces the fields we'd missed.
06What we learned
1. Usage data beats any written requirement. 2. Rebuild the core, not everything. 3. Configurability is an investment: every choice left to the user is one less development request. 4. Keep everything inside the ticket: information one click away is information that gets used.