AI for Elevator Maintenance Companies: Callbacks and Inspection Records

An AI agent for an elevator maintenance company can keep a clean, searchable trail of callbacks, upcoming inspection dates and technician notes, and it can route open items to dispatch and the office. It should not decide whether a unit is safe to run. That judgment, and the sign-off that goes with it, stays with a qualified person who inspected or repaired the equipment.

Key takeaways

• Every callback should sit on a single unit record with the reported symptom, the visit, the finding and the closure status, so a repeat call is visible before a technician drives out.
• Inspection due dates belong in a register the office can see. Requirements are set by the jurisdiction and the qualified person responsible for the account, and the agent only keeps the register current and raises warnings.
• Technician notes are most useful when captured at the site, in plain language, and linked to the unit and the callback.
• An agent can draft, remind, route and flag gaps. It should not mark a unit as safe, compliant or returned to service.
• Start with one narrow workflow, expand only after the records hold up under review, and keep a log of what the agent read and proposed.

Why callbacks are the right first workflow

A callback is any return visit to a unit after a service call was closed, or after a reported problem was not resolved on the first attempt. For many elevator service businesses the callback is where trust is won or lost, because the building manager remembers the second visit more than the first. It is also where records most often drift. The dispatcher logs the first call, the technician writes a few lines on a paper ticket, the parts order lives in a supplier email, and the callback arrives with a new description of the same fault.

That drift is a records problem before it is a technical one. An AI agent is useful here because it can hold the thread: match a new complaint to the correct unit, pull the prior visits, show any open parts order and tell the dispatcher that a similar symptom has appeared before. It does not need to diagnose a controller to be useful. It needs clean inputs and a clear boundary around what it may change.

Good first candidates are narrow. One option is a daily list of open callbacks that have no recorded finding. Another is a draft summary for the account manager before a meeting with a building owner. A third is a reminder to a technician to complete the note after a visit, sent while the details are still fresh.

Which records the agent should hold

A working record for each unit usually needs the following fields, kept in one place that the agent can read and the office can audit:

• Unit identifier, site address, equipment type, and the controller or drive model as recorded at installation or at the last survey.
• Service history: each call, its date, the reported symptom in the customer's words, and the technician who attended.
• Callback link: which earlier visit the new call relates to, and whether a person confirmed that relationship.
• Parts and orders: what was fitted, what is on order, and which supplier confirmation is still pending.
• Inspection register: the required inspection type for the unit, the date of the last completed inspection, and the date the office has scheduled for the next one.
• Open commitments: anything promised to the customer, such as a follow-up visit, a quote or a document.

Keep the source of each field visible. A date copied from an inspection certificate should be marked as copied, with the document reference beside it. That single habit shortens later disputes, because anyone reviewing the record can see whether a date was entered from paper, from a report or from a conversation.

Tracking inspection due dates without deciding compliance

Inspection requirements differ by jurisdiction, by equipment type and by the body that performs the inspection, so no general rule should be hard-coded into an agent. The compliance lead or the qualified person responsible for the account should define the required inspection types and how each due date is calculated for each unit group. The agent's job is to keep the register current, compare it with the schedule the office has set, and raise warnings early enough that someone can act.

A practical arrangement has three layers. The inspection rules are written by a qualified person and stored as a reference document the agent reads. The agent calculates which units fall inside the warning window the office has chosen and lists them for review. The office books the visit, and the qualified person confirms the outcome and any defects. The agent never converts "due soon" into "compliant," or "past due in the register" into "non-compliant," on its own authority. It can say that a due date recorded in the register has passed, and it can show where that date came from.

This separation matters because stale data is common. A unit may have been inspected by another contractor, a certificate may be filed under an old unit number, or a modernization may have changed what needs checking. The agent should flag those mismatches rather than resolve them silently.

The agent can show what the register says and where it came from. Only a qualified person can say what the equipment's condition means.

Technician notes: capture them, and know what they can say

Technician notes are often the most valuable and the least structured part of the record. A useful note says what was observed, what was tested, what was adjusted or replaced, what remains open, and what the customer was told. A weak note says "fixed door." The agent can help by prompting for missing details after a visit, turning a dictated or typed note into a structured entry for the technician to review, and linking that entry to the unit and the callback.

The boundary is equally important. A technician may write that a specific check was performed and that the result was logged in the controller's diagnostic history. The agent may store that statement and show it to the office. It should not generate a safety conclusion, rewrite a finding into a more reassuring one, or mark a unit ready for return to service. Safety status is confirmed by a qualified person who is accountable for it, and the record should show who confirmed it and when.

Human approval belongs inside the workflow, not at the end of it. Any change to a safety-relevant field, such as a defect status, an inspection outcome or a return-to-service flag, requires a named qualified person to confirm it. The agent can prepare the change and gather the supporting evidence. It cannot complete the change.

Illustrative scenario: a callback that returns twice

Illustrative scenario, not a real client case: a dispatcher receives a call from a building manager describing an intermittent door reopening problem in a mid-rise office block. The agent finds an earlier callback on the same unit, closed with a note that a door sensor was adjusted. It also finds a parts order marked as received, with no fitting record attached. It places both items beside the new call in the dispatcher's queue, drafts a short summary for the technician and flags that the earlier closure has no finding confirmed by a qualified person.

The dispatcher decides who attends and what to bring. The technician records the finding on site. The qualified person reviews the note before the new callback is closed. The agent then links the parts record to the fitting entry once a person confirms it, and it sends the building manager a status update containing only facts the office has approved. Nothing in that flow moves past the point where a human has to judge.

A step-by-step plan for the first engagement

A first engagement should be small enough to check by hand. A workable sequence looks like this:

• Choose one unit group or one account where callbacks are frequent enough to matter and clear enough to audit.
• Write down the inspection types and due-date rules for that group, and have the responsible qualified person sign them off.
• Copy the existing callback and inspection data into one structured register, marking each field as confirmed from a document or as inferred from another record.
• Define the agent's allowed actions: read the register, draft summaries, create reminders, route items to named people, and propose field updates for review.
• Define the blocked actions: changing a safety status, closing a callback without a confirmed finding, sending any statement about return to service, and editing an inspection outcome.
• Run the flow for an agreed period while the office reviews every proposed update, and record each disagreement with its reason.
• Measure whether callbacks link to the right units, whether warnings arrive early enough to act, and whether technicians complete their notes after visits.

The same pattern appears in other service businesses. The auto repair shop workflow for estimates, job status and parts and the maintenance requests in property management both depend on linking a complaint to the correct asset and history before any action is taken.

How Be Human handles this in a managed setup

Be Human designs the register, the agent's memory of the account, the tools it can call and the approval points that sit between a draft and a record. The first engagement defines one role, such as a callback and inspection coordinator, with an observable success criterion that the operations lead agrees to in advance. Managed operations then cover monitoring of the workflow, recurring checks that the agent still follows the agreed inspection rules, permission review when staff or systems change, and controlled improvements. The qualified person's sign-off stays in the system as a required step, not as a courtesy.

Permissions, audit trail and what stays with people

An agent that reads and writes service records needs the same discipline you would apply to a new dispatcher. Each tool should have only the access its role requires, and write access to safety-relevant fields should sit behind an explicit approval. The OWASP Authorization Cheat Sheet recommends checking access on each request rather than assuming that a request from an approved workflow is allowed, which suits an agent that calls several systems. The NIST AI Risk Management Framework treats documentation, human oversight and ongoing monitoring as part of managing AI risk, and those are the practical habits here: keep a log of what the agent read, drafted and proposed, and review that log on a fixed schedule.

For traceability, the OpenTelemetry observability primer explains how logs, metrics and traces help reconstruct what a system did and why. Applied to service records, each agent action should carry the unit identifier, the source document, the time and the name of the person who approved any change. Ask that the log be readable by someone who was not involved in the callback, because that is the test a building owner, an auditor or a new technician will apply. If you want to find the first task in your service operation that is worth handing to an agent, take the free Be Human AI diagnostic.

Frequently asked questions

Can an AI agent tell whether an elevator is safe to run? No, and it should not be set up to try. The agent can show the latest recorded inspection, the open defects and the technician's notes, and it can flag a missing or conflicting entry. The conclusion about safety belongs to a qualified person who is accountable for the unit, and that confirmation should be recorded with their name and the date.

What is the best first workflow to hand to an agent? Most companies start with open callbacks that have no confirmed finding, because the gap is visible and the fix is mostly organizational. A daily list, a draft summary before a customer call and a reminder to complete technician notes are all narrow enough to review by hand. Expand only after the office trusts the links between callbacks, units and parts.

Does the agent replace our dispatch or field service software? Usually it does not. The agent works alongside the system of record, reads what it is permitted to read and drafts or proposes changes for people to approve. Where the existing software has no clean way to link callbacks to units, the first project may be a register that the agent and the office both use, rather than a new platform.

How do we keep technician notes accurate when people are busy on site? Make the note short and structured, with prompts for the fields that matter most: what was observed, what was done, what remains open and what the customer was told. The agent can request missing details after the visit and present a draft for the technician to correct. Accuracy improves when the note is part of closing the job, and when the qualified person checks safety-relevant entries before the callback is marked complete.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.