After go-live: putting support, spares and SLA in writing

Once a visual AI SOP system is running, most disputes come down to three things: how fast you respond, who pays for spares, and whether a rule change counts as covered service. Leave any of the three out of the contract and you will almost certainly fail to agree on it later, mid-changeover or mid-breakdown. The goal is not a long SLA — it is to split “respond” apart and write the boundaries down.

Split “response” into three, and half the disputes disappear

A clause like “four-hour response” binds almost nobody, because no one can say when the four hours start or what counts as a response. A workable approach breaks the service into three intervals, fixes a time for each, and states whether each covers business hours only or the clock.

Spares: the list matters more than the discount

In after-sales negotiation, attention usually goes to the spares discount. But what decides downtime is not the discount — it is whether a replacement part is on site. The hardware in a vision system is not complicated, and how quickly a station recovers usually comes down to whether the consumable parts were thought through in advance. Rather than bargaining over a percentage, the spares list, its cycles and its supply route belong in the agreement. Over the life of the system, the spares policy moves the total cost of ownership more than a one-off price negotiation, a point that connects to visual SOP budget and ROI.

• A consumables list with model numbers. Camera, light, lens, industrial PC, cabling — each with its model and a recommended stock quantity.
• Replacement cycles and the judgement. Lights have a finite life; state at what degradation output they count as due for replacement, and who decides.
• Supply lead times. Time from order to dispatch, and whether discontinued models have a substitute.
• Who may swap what. Which parts the customer can replace and which require the vendor or an authorised party, so responsibility stays clear.

Data and configuration ownership

A vision system generates images and decision records continuously, and it accumulates a set of models and rules. Settle ownership of both at contract stage: the decision records are the customer’s production data and should be exportable at any time in an open format, while the models and rules should be handed over or migrated if the service ends. Both clauses exist to prevent being locked in to a single vendor, and both bear on whether traceability actually holds up — for the requirement behind it, see visual SOP data traceability, and for the interface side, visual SOP and MES integration.

Rule changes: the most overlooked item after go-live

Changeovers, new part numbers and small process tweaks all change the detection rules. This is routine demand, not a fault, so it usually falls outside “free fault maintenance”. Two approaches are common: change work priced per case, or an annual rule-maintenance package. Whichever you pick, three things must be agreed in advance — the scope and turnaround of a single change, such as how many days to configure the rules for one new part number; whether a change includes on-site sampling and validation or is remote configuration only; and how many changes are included per year, with the price of anything beyond that. These three matter because a vision system tends to prove its worth in the second and third year, which is exactly when changeovers are most frequent. Say how rule maintenance will work, and the system will not be shelved in year two for being too hard to change. For the adjustment rhythm in the early months, the visual SOP rollout timeline describes the settling period.