Support and SLA / Nimex Solutions
Support built around business continuity, accountability and resolution.
When a delivery cannot be validated, your warehouse does not need a ticket number; it needs the dock moving again and a clear answer on why it stopped. Our end-to-end 24/7 technical support gives every incident an owner, an investigation on the right environment, a tested fix and a closure you confirm. Service levels are defined per contract, in writing.
- How we work
- Standard Odoo
- Defined per contract
Channels
One queue, whichever way the question arrives.
Every request becomes a ticket with an owner, a priority and a state your team can see. The channels below are what we run; which of them your contract covers, and in which hours, is written in the agreement.
Helpdesk portal and ticketsHow we work
The primary channel: your users open tickets, attach screenshots and follow the state. Everything else is logged there too.
E-mailHow we work
Messages to the support address create tickets automatically; replies stay on the ticket thread.
Scheduled meetingsHow we work
Weekly or monthly review calls with your key users: open tickets, recurring issues, planned changes.
Phone and messagingDefined per contract
A direct line for critical interruptions, and messaging channels, are agreed per contract together with the coverage hours.
Severity examples
Incidents are not feature requests, and both get a clear path.
Priority follows business impact, not who shouts loudest. The examples below are how we classify; the response objectives attached to each level are set in your contract.
| Severity | Typical example | What it is | How it is handled |
|---|---|---|---|
| Critical interruption | Nobody can log in; invoices cannot be posted on the last day of the month; the production database is unreachable. | Incident. The company cannot run a core process. | Immediate ownership, workaround first, root cause after service is restored. Objectives per contract |
| Major workflow failure | Deliveries cannot be validated because of a serial number error; e-invoices are rejected by the provider. | Incident. One workflow is down; a department is blocked. | Reproduced on staging, fixed and tested there, deployed in an agreed window. Objectives per contract |
| Limited user issue | One user's report prints with a wrong column; a filter does not save for one person. | Incident. A user is slowed down; the workflow continues. | Investigated in the queue order; often a configuration or access-rights change. |
| General question | "How do I split a manufacturing order?" "Which report shows margin per customer?" | Question. No malfunction; knowledge is needed. | Answered on the ticket, added to the manual or to the next training round. |
| Enhancement request | A delivery slip in two languages; a new approval step on purchase orders. | Change. New behaviour, not a defect. | Estimated and scheduled as a change; not an incident, so never in the incident objectives. How we work |
SLA framework
What a support contract defines, and what it does not.
"End-to-end 24/7 technical support" is our promise of ownership: a reported incident is never without a person responsible for it. The measurable part is written per contract, because a two-site manufacturer and a ten-user distributor do not need the same coverage. We do not publish universal response times, resolution times or availability percentages.
- CoverageHours and days per severity level; what "24/7" means for critical interruptions in your contract.
- Response objectivesPer severity: when a ticket is acknowledged and owned, and how progress is reported.
- EscalationWho is called at each level and when, including your own contacts.
- ResponsibilitiesWhat your key users do (reproduce, confirm), what we do, what the hosting provider does.
- PrioritiesThe severity scale above, agreed with examples from your business.
- ExclusionsChanges, new developments, third-party outages, data entry errors: handled, but outside incident objectives.
- ReportingMonthly ticket report: volumes, states, recurring issues, time spent.
- Maintenance windowsWhen deployments and updates happen, and how they are announced.
Escalation and ownership
Seven steps, one owner at each, nothing closed before you confirm.
A ticket moves forward only when the step is actually done: a fix that is not tested is not a fix; a deployment the user has not verified is not a resolution. The same path applies to every severity; what changes is how fast each step is owned.
- IntakeThe request becomes a ticket with the reporter, the record and the screenshots.
- TriageIncident or change; severity by business impact; owner assigned.
- InvestigationReproduced on staging; logs, data and configuration checked.
- FixConfiguration, data correction or code change, in the right environment.
- TestingThe fix and the surrounding workflow tested on staging before deployment.
- Customer confirmationYour user verifies on production; the ticket waits for that.
- ClosureRoot cause documented; preventive change scheduled if needed.
Incident console
The same incident, as the support team sees it.
The queue by severity, the affected workflow, the escalation path with the level that currently owns the ticket, the root cause once it is known, and the resolution timeline. The counters move only when a ticket really changes state.
What this console does not show. No response or resolution times: those are objectives in your contract, reported monthly against real tickets. No availability percentage: hosting and monitoring are described on the hosting and maintenance page.
Monitoring and improvement
Fewer tickets next month is the goal of this month's tickets.
Support is also the place where recurring problems become preventive work. These are the routines behind a support contract; the monitoring of servers and databases themselves is part of hosting and maintenance.
Error analysisHow we work
Server and client errors are grouped by cause, not by ticket; the top causes get a preventive change.
LogsHow we work
Application logs reviewed after deployments and on every incident; retention according to the hosting model.
Recurring incidentsHow we work
Tickets that come back are linked; the third occurrence opens an improvement item instead of a third fix.
Technical debtHow we work
Workarounds and quick fixes are listed with their cost; the list is reviewed in the monthly meeting.
PerformanceHow we work
Slow reports, long-running jobs and heavy views are measured and tuned before users report them.
Preventive maintenanceHow we work
Scheduled updates, dependency reviews and clean-ups in the agreed maintenance windows.
DocumentationHow we work
Every closed incident with a root cause updates the manual or the configuration notes.