Custom Software for Elevator and Lift Service Companies

An elevator company is a contract business that runs like a repair shop

Strip away the equipment and an elevator or lift service company is a recurring-revenue business with a regulated product. You sell coverage on specific units for a term of years. That coverage obligates you to a maintenance interval, a response time, and a defined list of what you will and will not pay for. On top of that sits the actual work — scheduled maintenance visits, callbacks at two in the morning, state inspections with a witness present, violation corrections, modernization proposals, and parts that take eleven weeks to arrive for a controller nobody has manufactured since 1998.

Most independents under a few thousand units run that on a route book, a contract folder, a dispatch whiteboard or a generic field service app, and a set of spreadsheets that carry the parts the software cannot express. The workbook holds the inspection due dates, the coverage exceptions negotiated with three large property management clients, the callback log, and the list of units that are consuming more labor than they generate. It works, in the sense that the trucks roll and the invoices go out. It also means the business cannot answer its two most important questions — which contracts are actually profitable, and what is due next month — without someone opening a file and thinking.

What makes this industry an unusually good candidate for a targeted build is that the revenue is contractual, the obligations are legally mandated, and the cost side is volatile. Those three things together mean small tracking errors do not stay small. A missed inspection is a shutdown and a fine. A callback misclassified as covered is free labor repeated hundreds of times a year. A contract renewed at last year's escalator on a unit that has become a labor sink is a five-year loss you signed voluntarily.

Where off-the-shelf field service software breaks

Generic field service platforms are real products and worth evaluating seriously before building anything. What they encode is a dispatch business: customers, jobs, technicians, time, invoices. An elevator company is a coverage business attached to regulated assets, and that difference is where the spreadsheets start.

• The unit is not a first-class record. Field service software is organized around a customer and a job site. Your business is organized around a specific piece of equipment with a serial number, a controller type, a hoistway, a machine, a door operator, a governor, and a service history that outlives the building owner. When the unit is just a line of text in a job description, nothing about it can be tracked, reported, or priced.
• Coverage cannot be expressed. Full maintenance, limited coverage, oil-and-grease, parts-excluded, obsolescence clauses, negotiated exclusions with a major property manager. This is the single most important commercial fact about each contract and it usually lives in a PDF in a folder, which means the person deciding whether tonight's callback is billable is guessing.
• Compliance dates are tracked by hand. Periodic and five-year full-load tests, jurisdiction-specific intervals, witness requirements, certificate expirations, and the corrections that follow an inspection. Most companies hold this in a workbook that one person maintains, which is why a due date is typically discovered by letter rather than by report.
• Callbacks have no cause code and no coverage decision. The ticket says "door fault, adjusted and cleared." It does not say which component, whether the cause was covered, whether this is the fourth time on the same unit this quarter, or whether anybody should have billed for it.
• Route maintenance is scheduling, not obligation. The contract says you will be there monthly or quarterly. A calendar-based scheduler will happily let a visit slip a month, and at renewal you cannot prove you performed what you sold — which is exactly the document a client asks for when they are shopping the contract.
• Per-unit economics do not exist. Revenue is allocated at the contract level, labor is captured at the job level, and nothing rolls up to the unit. So the question "which of these 340 units lost money last year" gets answered by instinct, usually by a service manager who is right about the worst five and wrong about the rest.

The diagnostic is the same one that works in every service business: find the spreadsheets. In an elevator office they are almost always an inspection due-date tracker, a callback log, a contract terms summary, and a parts-on-order list. Those four files are a precise specification of what your current software does not do — the general form of that signal is in when to replace your spreadsheets with custom software.

The unit record is the foundation, and it is usually scattered

Everything in this business resolves back to one question: what is this unit, and what did we agree to do for it. If that record is authoritative, dispatch, compliance, billing, and renewal all become mechanical. If it is not, every downstream decision inherits the ambiguity — and the ambiguity is resolved by whichever technician or coordinator happens to be closest to it.

A working unit record holds the identifying detail a technician needs before rolling (type, capacity, controller and drive, door operator, machine, governor, year installed and last modernized), the location detail dispatch needs (building, bank, machine room access, after-hours entry, who to call), the contract that covers it with effective dates, the maintenance interval and task list owed under that contract, the compliance calendar with last and next inspection, open violations, and the full service history including every callback with its cause.

The design detail that matters most is effective dating. Contracts renew, coverage terms change, buildings change hands, and a unit gets modernized halfway through a term. A system that only knows today's state cannot explain why a callback in March was billed the way it was — and that explanation is precisely what a property manager asks for eight months later when they dispute the invoice.

Compliance is the feature that justifies the build

Mandated inspection is the part of this business with no tolerance for a tracking error. A periodic inspection that lapses can take a unit out of service, and a unit out of service in a medical building or a high-rise residential property is not a scheduling inconvenience, it is a phone call from a very angry owner and sometimes a fine.

The build here is small and the payoff is disproportionate. Encode the compliance rules once — which category each unit falls into, the interval required by that jurisdiction, what witnessing the test requires, how long a certificate stays valid, and what happens when a correction is issued. Then drive the schedule from the unit, not from a coordinator's calendar. Everything due in the next ninety days should be a standing view, assignable to a technician with the test equipment and the qualification to perform it, with certificates and correction notices attached to the unit rather than filed in a drawer.

The document trail this accumulates is substantial — certificates, test reports, violation notices, correction confirmations, and the signed tickets that prove you were there. Keeping that retrievable per unit rather than per folder is the subject of custom document management software.

Callbacks are where the margin leaks

Scheduled maintenance is predictable. Callbacks are not, and they are where contract profitability is actually decided. Two problems compound. The first is that nobody determines billability while the information is fresh, so work that the contract explicitly excludes — vandalism, water in the pit, a tenant holding a door, an obsolete component outside the coverage schedule — gets performed for free because the ticket reached the office three weeks later in handwriting.

The second is that nobody sees the pattern. A unit generating one callback a month is telling you something specific: a door operator that needs replacement, a controller at the end of its life, a building with an environmental problem, or a client whose tenants are causing it. Each of those has a different commercial answer — a repair proposal, a modernization conversation, a coverage renegotiation, or a billable pattern you should be invoicing. None of them is available while the callbacks are individual tickets rather than a count against a unit.

What to build is straightforward: capture cause code, coverage determination, parts used, and time on the ticket at the unit, flag anything potentially billable for same-week manager review, and maintain a running callback count per unit that is visible to whoever prices the renewal. Companies that put this in place usually find callback volume is concentrated in a small fraction of units — and that the fraction was not the one they would have guessed. Turning that history into something a service manager can actually read is the subject of custom reporting software.

Per-unit profitability is the number the business is missing

Most independents can tell you what a contract bills annually. Far fewer can tell you what a unit costs to serve. The gap between those two numbers is the whole game, because contracts are portfolios — a building with six units is usually four profitable ones carrying two that are not, and the renewal is priced as if all six behaved the same.

Once the unit record and the service history are clean, this stops being an accounting project and becomes a calculation. Allocate contract revenue across covered units. Attribute maintenance labor, callback labor, after-hours premium, parts, and travel back to the unit that consumed them. What emerges is a ranked list nobody in the company has seen before: which units earn, which units bleed, which clients' portfolios are healthy, and where the escalator in the next renewal needs to be something other than the standard one. The general discipline for deciding whether a build like this pays for itself is in how to calculate the ROI of custom software.

Getting the resulting invoices and costs into the books without re-keying is its own question, and usually a smaller one than it appears — the patterns are in custom software with QuickBooks integration.

Give property managers a view instead of a phone call

A meaningful share of the administrative load in an elevator company is answering the same four questions for property managers: is my unit running, when were you last here, when is the inspection due, and what is the status of that repair proposal I approved in June. Every one of those answers already exists in the system you are building. Exposing them removes work rather than creating it.

This is also the most durable competitive argument an independent has against the national companies. A property manager with fifteen buildings who can see service history, compliance status, and open proposals in one place is materially less likely to take a cold call seriously at renewal. What belongs behind that login and what does not is covered in what a client portal is and whether your business needs one.

What to build, in what order

The failure mode here is scope. Units, contracts, dispatch, mobile tickets, compliance, parts inventory, proposals, billing, a client portal, and profitability reporting in one build is a long project with a real chance of stalling, and none of it is necessary at once.

Start with the unit record and the contract that covers it, because every other feature is a property of a unit with coverage, a history, and a due date. Add the mobile ticket next — cause code, coverage determination, time, and parts captured at the unit is what stops the margin leak and what populates the history everything else depends on. Compliance scheduling comes third, since it is the highest-consequence item and becomes nearly free once units carry their own dates. Per-unit profitability reporting follows, because by then the data exists. The client portal and proposal pipeline last, as they benefit from everything underneath being solid. Sequencing a build this way is the subject of how to scope a software project.

When an elevator company should not build anything

Three situations argue against a custom build, and each is worth ruling out before a discovery call.

If you run a few dozen units on paper and have never used a field service platform, start there. A licensed product will fix your dispatch and your invoicing for a fraction of the cost, and you will learn what it cannot do. The economics turn when the workbooks beside the platform start carrying your coverage terms and compliance dates rather than your edge cases.

If you already license something and use a third of it, look there first. It is genuinely common to be paying for an asset module or a customer portal inside a product you own and abandoned when the configuration stalled during a busy season.

And if two people in your office would classify the same callback differently, settle that before writing any code. Software will encode the disagreement and apply it consistently at scale, which is worse than the spreadsheet — the spreadsheet at least made someone stop and think. Which situation you are in is the subject of seven signs your business has outgrown its software.

How we approach it

Brad Walker has spent more than twenty years building operational systems for service contractors, field organizations, and multi-location operators from Wake Forest, NC. An elevator engagement starts by following one month of callbacks end to end: what came in, which unit it hit, what the contract actually covered, what the technician wrote down, what got billed, and what quietly did not. That trace usually explains most of the margin gap in the business and defines a build small enough to finish.

Engagements are fixed price, with the scope agreed before development starts. You know what you are getting, what it costs, and when it lands.

Frequently asked questions

If your inspection due dates live in a workbook and nobody can tell you which units lost money last year, that is a fixable problem — and a smaller build than it feels. Start the conversation. The first step is a discovery call to trace one month of callbacks from the phone to the invoice.