Getting Technicians to Log Work They Have Actually Done

The consequence is well known and worth stating once: the log gets completed at the end of the week from memory, and the data becomes fiction that still gets reported. Everything below is about the interface decisions that prevent that, and most of them remove something rather than add it.

1. Work offline by default, not as a degraded mode

Plant rooms, basements, lift shafts, rooftop enclosures and service corridors are where this work happens and where signal is not. A system that needs connectivity to record a completion will be used in the car park afterwards, which means from memory.

The requirement is that capture completes locally and syncs later, silently, with the technician never waiting on a spinner and never losing an entry because they walked into a stairwell. If offline is described as a fallback rather than the normal case, it has been built the wrong way round.

2. Four required fields, and defend the fourth

Every stakeholder wants one more mandatory field, and each addition is individually reasonable. The aggregate is a form nobody completes honestly — people type anything to get past a required box, which is worse than not asking, because now the data looks complete.

Keep the mandatory set to what is genuinely needed to close a job and make everything else optional. Optional fields do get filled when the technician has something to say; mandatory ones get filled with a full stop when they do not.

3. Choices, not typing

Typing on a phone with gloves on, in bright sun, one-handed, is the worst input method available. Almost everything worth capturing is a choice from a short list: what was done, what was replaced, what state it was in, whether it needs a return visit. Buttons and pickers, sized for a thumb.

This is also what makes the condition record realistic. A three-option judgement — still serviceable, due, overdue — is two taps. A free-text description of wear is a paragraph nobody writes, and an empty field teaches you nothing.

4. The camera is the best field on the form

A photograph takes a second, needs no language, and carries more than a paragraph would. It also settles disputes: what the part looked like, what the leak was doing, what the panel read. Two photos, before and after, are worth more than any description field and cost the technician almost nothing.

The system side has to hold up: photos captured offline, queued, uploaded later, compressed sensibly, and attached to the asset rather than only to the job.

5. Arabic, and the technician's own keyboard

A field workforce in Oman is multilingual, and the person logging the job may be most comfortable in Arabic. The interface has to work in Arabic properly — mirrored, not merely translated — and free-text notes must accept Arabic and survive into every report and export. A note that arrives at head office as question marks was a wasted keystroke and the technician learns not to bother.

6. Give something back at the point of use

This is the rule that changes adoption rather than compliance. A technician standing in front of an asset should be able to see what that asset's history is: when it was last serviced, what was replaced, what the last person noted, whether this fault has happened before.

That turns the system from a reporting obligation into a tool that makes the job easier — and it is the only mechanism that reliably produces good data, because the person entering it becomes the person who benefits from it having been entered.

7. Make the exception path faster than the workaround

Jobs go wrong: the part was not on the van, access was refused, the tenant was out, the fault was something else entirely. If the system has no quick way to say that, the technician closes the job as complete and tells a supervisor verbally — and your planned-versus-reactive figures quietly stop meaning anything.

A one-tap "could not complete, because" with a short reason list is the fix, and it is the field that most improves the quality of everything else you measure.