A passenger is stuck and the paperwork starts later
The call comes in at ten past six on a Friday evening. Someone is stuck in the lift at a block of flats, the auto-dialler in the car has connected to your answering service, and the operator is reading details off a screen. They email the job across, text the on-call engineer and ring the duty manager. Somewhere in that chain the times start to blur.
The engineer is on the M62, forty minutes away, and says so in a reply text. The building's concierge rings your office line separately to ask where the engineer is. The engineer arrives, releases the passenger, finds a door lock fault, resets and leaves the lift running or switches it off pending a part. The job sheet gets filled in the next morning from memory.
On Monday the managing agent emails asking for the entrapment report: time of call, time of arrival, time of release, cause, and whether the lift is back in service. Your office manager opens four different places to answer one email, and two of them disagree by twenty minutes.
Why the timeline never lines up
The problem is not that nobody records the times. It is that four different systems each record one piece, and none of them is the job record. The answering service has the call time. The phone has the text. The engineer's app or paper sheet has arrival and departure. The office has the customer's follow-up calls in a notebook or a shared inbox.
- The answering service logs the call but sends it as an email or PDF, not as a job in your system.
- Engineer arrival is often typed in afterwards, so it is an estimate rather than a stamp.
- Release time and return to service are two different events that get written as one.
- Follow-up calls from the building are not attached to the job at all.
- If a second engineer attends, their times sit on a separate sheet.
Entrapments are the call-outs your customers watch most closely, and many maintenance contracts set out how they should be reported. When the record is assembled by hand after the fact, it is slow to produce and easy to challenge.
The cost is felt in the week after
Each entrapment turns into admin: an hour chasing times, a call to the engineer, a reply to the agent, maybe a second reply when the agent spots a gap. Across a portfolio with hundreds of lifts, that is a steady drain on the people who should be planning visits.
There is also a commercial cost. Contract reviews and tenders often ask for your attendance record on entrapments. If you cannot produce a clean list quickly, you are arguing from memory against a customer who has their own concierge log. And when a record looks patched together, it invites questions about everything else in your service reports.
A call-out log that fills itself in as the job happens
We build an entrapment and breakdown log that sits alongside your existing job management software and captures each step at the moment it happens, rather than asking anyone to type it later.
- Answering service emails or webhooks are parsed on arrival, so the call time, site, lift reference and caller details create a live call-out record straight away.
- The on-call engineer receives the job on their phone with the lift's details and taps to accept. That tap is the acknowledgement time.
- Arrival is recorded by a tap on site, with the phone's location checked against the site address so a mistaken tap is flagged.
- Release of the passenger and return of the lift to service are separate buttons, with a required note if the lift is left switched off.
- Calls and emails from the building about the same job are matched by site and attached, so the office sees the whole conversation in one place.
- When the job closes, a short entrapment report is produced from the record and can be emailed to the customer or placed in their portal.
| Step | Where it is recorded today | Where it is recorded after |
|---|---|---|
| Call received | Answering service email | Call-out record, created automatically |
| Engineer accepts | Text message reply | Tap in the engineer app |
| Arrival on site | Job sheet, filled in later | Tap on site, location checked |
| Passenger released | Often not recorded separately | Its own timestamp |
| Lift back in service | Merged with release time | Its own timestamp and note |
If your job management system has an API, the record is written back there so nothing lives in two places. If it does not, we keep the log in a small web app and export to your system on a schedule.
What Monday morning looks like after the change
The agent's email asking for the entrapment report gets a quick reply, because the report already exists. The office manager is not ringing engineers to ask what time they got there. Engineers stop being asked to remember Friday evening on a Monday.
Over a few months you also get something you could not see before: entrapments by site and by lift, how often the same lift traps people, and which times of day your on-call cover is stretched. That is useful when you are deciding whether a lift needs more than repairs, and it gives you honest numbers for contract reviews rather than estimates.
We do not change how your engineers work on the lift itself. The system only records what happened, when, and who did it.
Does this sound like your office?
- Entrapment reports are written by hand after the event.
- Your answering service sends jobs as emails that someone retypes.
- Release time and return-to-service time are recorded as the same thing.
- Customers have questioned your attendance times using their own logs.
- You could not quickly list every entrapment on one lift in the last year.
If several of these are familiar, the gap is in how the call-out is captured, not in how your engineers respond.