Incidents solved the same day

Picture the scene. A technician is finishing an installation in a shopping centre. Four streets away, a screen belonging to a client of the same integrator has been flickering for three days. It is twenty minutes of work: reconnect, check, done. But nobody knows. The incident waits in a list for someone to organise a trip, the technician drives back to base, and next week somebody will do forty kilometres for those twenty minutes.

That crossing of wasted coincidences happens every day, and it is the gap we want to close. The idea is simple: if there is a small incident near where a technician is working, Level AV could let them know. A discreet notice, along the lines of “when you finish, there is a minor fault 5 minutes away, do you want to take it?”. The technician would see the essentials before deciding: what is failing, where, and the context of the original installation, so they know what they are walking into.

The key word is “decide”. This idea only works if the technician is in charge of their own time, so the design starts from a rule we are not going to move: nothing is imposed. The technician accepts or declines, and declining carries no penalty: not to their visibility, not to their reputation, not to their relationship with the integrator. Maybe they are in a hurry, maybe another site is waiting, maybe they simply do not feel like stretching the day out. All of those are valid reasons and none of them needs explaining. A notice is an opportunity, not an order.

If they accept, everyone comes out ahead. The technician adds a short job with almost no travel: extra billing for the price of a few minutes' detour. The integrator solves in hours what today takes days, without arranging a dedicated visit for a minor fault. And the client sees their screen working the same day somebody happened to be in the neighbourhood, which is the kind of service people remember.

This idea fits with two others we are exploring. With post installation support, because incidents would come in with context already attached: what was installed, what is failing, what the end client said when reporting it. And with optimised travel, because they share the same conviction: the platform knows where the work orders are going to be, and that knowledge should save kilometres instead of sitting in a database.

There are questions still to resolve, and we want to resolve them with the people who are on site: what exactly counts as a “small” incident, how the price of that extra job gets agreed, how often it is reasonable to send a notice without becoming a nuisance. But before any of that we need to know whether the idea makes sense to you. If you are a technician, the question below is for you.