Industrial Training and Support: Operational SLAs That Actually Work

Industrial training and support are the invisible half of any business software project: the ERP or internal tool that works well today is the one somebody maintains, explains and fixes when it breaks. This guide covers what a genuinely operational SLA looks like and how to build user training that sticks.

Why software lives or dies by its support

A management system is not bought: it is lived with for years. Commissioning takes a few months; operation, a decade. And yet almost all the commercial, technical and budgetary attention concentrates on the first phase. The result is familiar: sound implementations that degrade because nobody answers incidents within a reasonable time, because new users learn by imitating the veterans (bad habits included), or because the documentation froze at the version from three years ago.

In an industrial environment, that degradation has a direct cost. If the ERP will not let you confirm a manufacturing order, the plant does not stop, but it starts working outside the system: paper delivery notes, consumption jotted in a notebook, reconciliations on Friday. Every hour of downtime or blockage generates data debt that somebody will have to pay off later. That is why the support contract is not an administrative annex: it is the piece that decides whether the initial investment keeps its value.

The thesis of this guide is simple: good support can be specified, measured and demanded, just as a machine is specified. The tool for doing so is the operational SLA. And its indispensable complement is continuous training, because an enormous share of support tickets are not software failures but symptoms of users who do not know how to use it.

What an operational SLA is (and what it is not)

SLA stands for Service Level Agreement: the document that fixes what service is provided, within what deadlines, during what hours, and what happens when it is not met. So far, the theory. In practice, many documents called SLAs commit to nothing verifiable.

An SLA is operational when it meets three conditions:

1. It is measurable without argument. Deadlines are counted from a recorded event (the ticket being opened) to another recorded event (the first qualified response, the resolution). If measuring compliance requires interpretation, there is no SLA: there is a statement of intent.
2. It distinguishes severities with objective criteria. Saying "critical incidents within 4 hours" is not enough. You must define what makes an incident critical, with concrete examples from the customer's business, so that vendor and customer classify the same case identically.
3. It has consequences. A deadline without a penalty, an escalation mechanism or a review right is a suggestion. The consequence need not be financial; an automatic escalation to a named manager often works better than a penalty nobody ever claims.

What an operational SLA is not: the phrase "24/7 support" without deadlines, an "average response time" without a percentile (an average can be dressed up with plenty of trivial tickets), or the classic "we will use our best efforts". None of those formulas lets you know, on a Tuesday at 10:00 with invoicing blocked, when somebody is actually going to attend to you.

Response time vs resolution time

This is the industry's most profitable confusion, and it is worth untangling before signing anything. They are two different commitments:

• Response time: how long it takes a qualified person to take charge of the ticket. Not an automatic acknowledgement: someone who has read the case, classified it, and either started working or asked for the missing information.
• Resolution time: how long it takes for the problem to be resolved or, at minimum, to have a provisional solution that restores operations (a workaround), with the definitive fix scheduled.

Many contracts commit only to the first. The vendor replies within 30 minutes with "we are on it" and the SLA is formally met even though the incident stays open for two weeks. A serious SLA commits to both, and on resolution accepts a reasonable nuance: for complex defects, the firm commitment is the workaround within the deadline, and the root fix goes into a dated release. It is an honest nuance, because nobody can guarantee that any bug can be fixed at the root within 8 hours; what can be guaranteed is that the shop floor is not left blocked.

A third deadline appears in mature contracts: the diagnosis time, the point at which the vendor communicates what is happening, why, and what plan it has. For the operations manager, knowing where they stand at the 2-hour mark is worth almost as much as the resolution itself, because it lets them decide whether to activate the manual contingency procedure or wait.

Severity levels with shop-floor examples

Severity classification is the heart of the SLA, and where it most often goes wrong. The key is defining each level by its impact on operations, not by the emotions of whoever opens the ticket. A reference table for an industrial environment with an ERP and management tools:

Two observations on this table. First: the specific deadlines depend on the contract and the price; what matters is the structure, not the exact numbers. Second: the definition of S1 must be written with the customer's real processes in front of you. "Critical" at a plant dispatching daily is not the same as at an engineering firm invoicing by milestones. An SLA copied from a template misclassifies from day one.

It also pays to agree the reclassification mechanism: who decides the final severity when customer and vendor disagree, and how the change is recorded. Without it, the argument over whether something "was S1 or S2" poisons the relationship more than the incident itself.

Anatomy of an SLA that can actually be met

Beyond severities and deadlines, a complete operational SLA specifies at least these elements:

• Coverage hours per severity. It is reasonable for S1 to have extended hours and S3 only office hours. What is not reasonable is for the hours not to be written down.
• A single intake channel. A ticketing system with date and time logging. The WhatsApp message to the trusted engineer is convenient until that engineer is on holiday and nobody knows what was asked of them.
• An escalation chain with names. If the response deadline is missed, the ticket automatically escalates to an identified manager. Escalation is not a punishment: it is the guarantee that no case is left orphaned.
• Customer obligations. The clocks pause while the vendor waits for information only the customer can provide. Making this explicit protects both parties and obliges the customer to appoint contacts who respond.
• A periodic service report. A monthly or quarterly summary with tickets opened and closed, deadline compliance per severity and recurrences. It is the raw material for the review meeting and for the training section that follows: repeated tickets show where training is missing.
• Maintenance windows and release management. When updates happen, with what notice, how they are tested before touching production and how they are rolled back if something goes wrong.

A note on penalties: they work better as a review mechanism than as a revenue stream. A common, healthy scheme accumulates measured breaches and, past a certain threshold, activates a right to renegotiate terms or exit early. The purpose of the SLA is not to collect fines: it is for the service to work.

User training that works: by role and at the workstation

The typical implementation training is a four-hour classroom session for all users, two weeks before go-live, with a projector showing screens that will still change. Three months later nobody remembers anything and support fills up with basic queries. This model fails for three specific reasons, and each has a remedy.

Train by role, not by system

The warehouse operative needs to master five screens and needs to master them blindfolded. The purchasing manager needs another eight, and administration, different ones again. The generic session touring "the whole system" serves nobody: it bores each attendee with the 80% that does not concern them and rushes through the 20% that does. Effective training is designed by role: what this person does on an ordinary Monday, in what order, and what they do when something goes off script (a return, a stock adjustment, an urgent order with no stock). The rare cases deserve more time than the frequent ones, because the frequent ones teach themselves through practice.

Train at the workstation, with real data

Watching a consumption entry on a projector is one thing; recording it with gloves on, at the shop-floor touchscreen, with the material in front of you, is another. On-the-job training, with the test environment loaded with the company's real articles, customers and orders, produces a level of retention the classroom never achieves. And it has a valuable side effect: walking through the real process exposes the gaps the design did not consider, while they are still cheap to fix.

Train close to go-live and repeat afterwards

The forgetting curve is unforgiving: what is learnt and not practised is lost within weeks. Initial training must sit tight against go-live, and the plan does not end there. The pieces that sustain knowledge over the long term are different: key user figures per area (the reference person who absorbs 90% of their colleagues' questions before they ever become tickets), refresher sessions at one month and three months focused on the errors support is actually seeing, and onboarding training for every new hire, because staff turnover is the silent mechanism by which an organisation unlearns its own system.

Living documentation: the kind people actually consult

The 200-page user manual delivered as a PDF at project close has a known destiny: a folder nobody opens. Not because documenting is useless, but because that format does not match how people look for help: at the moment of the problem, with a specific question, and in a hurry.

The documentation that does get used shares a few traits:

• Granular and task-oriented. "How to record a customer return" on a short page with screenshots, not chapter 7 of the manual. Each page answers one question.
• Searchable and reachable from the workstation. A knowledge base on the intranet or inside the system itself, not a file on somebody's drive. If finding the answer takes more than a minute, the user opens a ticket or, worse, improvises.
• With an owner and a date. Every document has someone responsible for maintaining it and a visible last-review date. Ownerless documentation goes stale in silence, and an obsolete instruction is worse than none: it teaches the wrong procedure with an official appearance.
• Fed by support. This is the circuit that keeps it alive: every repeated S4 query is a missing documentation page. The periodic SLA report flags the recurrences; the training plan and the knowledge base absorb them. Support, training and documentation are not three services: they are three faces of the same cycle.

For shop-floor procedures, the one-page work instruction format works particularly well (what I do, in what order, what I check before closing), laminated or fixed next to the workstation, along with the short two-minute video for interface-heavy processes. Both age, so both need an owner.

The cost of under-training

Training is easy to cut because its cost is visible and its benefit diffuse. It is worth doing the opposite exercise: putting in front of you what not training costs. The mechanisms are four, and all of them appear in any implementation that skimped here:

1. Inflated support. A substantial share of the tickets in any management system are usage queries, not defects. Each one consumes time from the user who opens it, the engineer who answers it and the colleague who gets asked first. It is the easiest cost to measure: classify a quarter's tickets and count how many would have disappeared with training or documentation.
2. Bad data. The user who does not understand a field fills it in any old way or leaves it empty. Months later, the margins report does not add up, the MRP proposes absurd purchases and management stops trusting the system. Retrospective data cleansing costs a multiple of the training that would have prevented it.
3. Parallel systems. Whoever does not master the tool takes refuge in Excel. First as a crutch, then as the real record, and the official system ends up being filled in after the fact, late and badly. When an implementation "never took hold", what frequently never took hold was the training.
4. Under-utilisation. The company paid for licences and consultancy on a system of which it uses a fraction, while processes the software already solves keep being done by hand. It is the most silent cost: it generates no tickets, it simply makes the investment yield less than it should, year after year.

Seen this way, the training budget does not compete with the support budget: it reduces it. A continuous training plan well targeted (by the support data itself) is the cheapest lever for lowering ticket volume and raising data quality.

Worked example: an incident in a plant ERP

To see how the pieces fit, let us follow a plausible incident from start to finish. Tuesday, 9:40. At a manufacturing company, the dispatch clerk tries to validate the day's delivery notes and the system returns an error. Two lorries are booked for 12:00.

1. 9:42. Opening. The logistics key user opens a ticket through the agreed channel: description, screenshot of the error, number of the affected delivery note. They propose severity S1: dispatch stopped, lorries waiting. The SLA clock starts here, with an objective record.
2. 10:05. Qualified response. Within the S1 deadline (45 minutes in this contract), an engineer confirms the S1 classification, reproduces the error in the test environment and asks for a missing piece of data. No automatic acknowledgements: the case is in the hands of someone who understands it.
3. 10:50. Diagnosis. The engineer communicates the cause: the latest update changed a validation and delivery notes with mixed lots no longer pass. They propose a workaround (validating those delivery notes from another screen that does not run the new validation) and test it with the key user over the phone.
4. 11:15. Operations restored. Dispatch validates the delivery notes through the alternative route. The lorries load on time. The ticket moves to "workaround applied": the S1 provisional-resolution SLA has been met, but the case does not close.
5. Friday. Root fix. The patch correcting the validation goes in during the agreed maintenance window, tested first in the test environment. The ticket closes with the cause documented.
6. Month end. Improvement cycle. The service report records the case: breaches, none; cause, a regression in an update. It is agreed to add mixed-lot delivery notes to the test battery run before every update, and a new page in the knowledge base explains the alternative screen. The incident leaves the system better than it found it.

None of the above is heroic. It is what a well-defined SLA produces when it is met: clocks that start on their own, severity without argument, a workaround that prioritises operations and a circuit that turns every incident into prevention and documentation.

How to evaluate a vendor's support before signing

Everything above can be verified before contracting. Concrete questions that separate real support from brochure support:

• Ask for the SLA document and look for the three elements: measurable deadlines per severity, severity definitions with examples, and consequences for breaches. If any is missing, ask for it to be added; resistance to doing so is already information.
• Ask whether the commitment covers response, resolution or both, and how they handle workarounds for complex defects.
• Ask for a real (anonymised) service report from another customer. Whoever measures their compliance can show it; whoever does not measure cannot meet anything.
• Ask who answers: the team that knows your installation or a generic first line that opens and closes tickets? In customised systems, the distance between support and development is paid for in every diagnosis.
• Ask about the training plan beyond go-live: refreshers, material per role, training for new hires, and how they use support data to target it.
• And an uncomfortable but useful question: do they support installations implemented by another vendor? The answer describes their real capacity to read and maintain systems they did not design, which is exactly what they will be doing with yours in five years' time.

At Captia we provide ongoing support and maintenance for Odoo installations, including those commissioned by other partners, and we build internal tools that are born with their support plan and documentation already in place. The SLA structure described in this guide is the one we apply in those contracts.

Frequently asked questions on SLAs and industrial training

If you want a support contract with deadlines that are measured and training that reduces tickets instead of generating them, at Captia we work with this SLA structure across management software implementations and maintenance. Tell us about your case and we will review it with you.