How I Would Build an Elevator Compliance System for a Property Portfolio

Direct Answer

An elevator compliance system is a portfolio register that holds every lift as an asset, derives what each one owes and when, and shows the ones that are not fine. Add a building, get thirty-seven lifts with a per-asset status: inspection due, certificate missing, finding open. This is a designed system, not a deployed build. It comes from the Shopify Your Industry lab and has never been sold to or validated with a customer.

Key Takeaways

• The whole product is knowing what is not fine. Everything else is filing.
• The product is the coordination layer: asset register, obligations, calendar, contractors, certificates, alerts.
• The bottleneck is cold start. Partial coverage is worse than none, because it looks complete.
• Obligations are largely national. The EU rules cover placing a lift on the market; periodic inspection and maintenance are set by each country.
• This is a model, like the freight booking system. The system I have actually built is the CRM follow-up loop.

What problem does this system actually own?

A property manager with twelve buildings holds inspection dates, maintenance contracts, and certificates across a filing cabinet, three inboxes, and one person who remembers things.

Today the path usually runs like this:

1. A maintenance firm calls to say an inspection is due, or does not call.
2. Someone searches an inbox for last year’s certificate to find the date.
3. A contractor is booked, sometimes late, sometimes twice for the same lift.
4. The inspector raises findings on a PDF that lands in a different inbox.
5. Nobody confirms the findings were closed before the next cycle.
6. A building changes hands or a manager leaves, and the history goes with them.

None of that is engineering. It is information moving between an owner, a manager, a maintenance firm, and an inspector, each holding one piece of it. That is the coordination layer, and it is the product.

The existing workflow I would map first

Before any model call, I would sit with a property manager and walk one building through one full inspection cycle.

If that table is wrong, the system is wrong. I would rather spend a week on the table than a month on the wrong build.

How the system would run

Asset registration

Every lift becomes a record: building, identifier, installation date, type, capacity, maintenance firm, and the last known certificate. Intake accepts what actually exists — a spreadsheet, a folder of PDFs, a photo of a plate in the machine room. The system extracts what it can and marks the rest as unknown rather than guessing. Unknown is a legitimate and visible state here.

Obligation discovery per asset

Each asset gets its obligations derived from rules: which periodic inspection applies, at what interval, and who may perform it. This is a rules engine with document classification on top, not a reasoning engine, and the rules are national. The EU framework governs the design, manufacture, and installation of a lift; maintenance and periodic inspection are set by each country. That means the rule set is per-jurisdiction, and a system built for one country does not silently transfer to the next.

Compliance calendar

Obligations become dated items across the portfolio, with lead times built in so a due date is not the first warning. The calendar is the product surface. It answers one question — what is not fine, and by when — and it distinguishes between an overdue inspection, an open finding, and a certificate that exists but is not filed. Those are three different risks and I would not average them into one score.

Contractor coordination

The system prepares and sends the request to the maintenance firm or inspector, tracks acceptance, and chases silence. It knows which visit belongs to which obligation, so a completed visit closes a specific item rather than a vague one. Where a contractor will only work by phone, the call is logged as the record. This is the step where the system either matches how the trade actually works or it does not.

Certificate storage

Documents arrive as email attachments, portal downloads, or photos. The system classifies them, extracts issue date, expiry, inspector, and findings, and attaches them to the asset. A document it cannot confidently classify goes to a human queue instead of being filed wrong, because a certificate filed against the wrong lift is worse than one not filed at all.

Renewal alerts

Alerts run off the calendar with escalation: the manager first, then the owner, then a weekly digest of everything overdue. Escalation matters more than intelligence here. A reminder nobody opens is not a compliance system, and I would measure open and resolution rates from the first week.

What stays under human control?

• The physical inspection, by a licensed inspector.
• Maintenance work, by a qualified firm.
• The decision to take a lift out of service.
• Confirmation that a finding is closed.
• Conformity assessment where a notified body is required, for example on a new or substantially modified installation.

The system prepares, a person signs. That is the same rule I follow in the CRM build, and Anthropic’s note on building effective agents makes the same argument: keep the workflow simple and inspectable before adding autonomy.

How I would measure the path

Baselines first, and only baselines, because nothing has been built:

• Assets with a complete record versus assets known to exist.
• Inspections completed after the due date, over the last two cycles.
• Certificates the manager cannot produce within an hour.
• Findings with no recorded closure.
• Days from a due date to a booked contractor visit.

Self-learning here means usage signals, manager corrections to obligation rules, and evaluation of document classification against what a person confirmed. It does not mean the system deciding on its own that an obligation no longer applies.

When this is the wrong build

• The portfolio will not be loaded. This is the bottleneck. Partial coverage produces false confidence, and false confidence in a compliance dashboard is a liability, not a feature.
• The maintenance firm already does this well. If one firm covers the whole portfolio and reports properly, the manager is buying a second copy of a working system.
• The portfolio is too small. Two lifts and one manager do not need a coordination layer. A calendar reminder is the correct answer.
• The rules are one country deep and the customer is not. A per-jurisdiction rule set is real work, and it does not amortise across a single-market customer.
• Nobody owns the outcome internally. If no named person acts on an alert, the system converts a filing problem into an ignored notification problem.

How this connects to the engagement

This case is one of the models on Shopify Your Industry. The freight teardown has the same shape and a different wall: there the supply side, here the empty register. The document capture and monitoring pattern is closer to the Deal Database. The one system on this site that is actually running is the CRM follow-up loop.

If this coordination layer already exists in your company as three inboxes and one person’s memory, the operating starting point is AI workflow automation. If you want it looked at honestly, describe the bottleneck. If you only want the next teardown, the newsletter is enough.

Summary

The abstraction is one line: add your building, see which lifts need action. The output is a portfolio that stays legal without anyone tracking it by hand. Between those sits a boring coordination layer moving information between an owner, a manager, a maintenance firm, and an inspector. This is a model. It stays a model until someone who manages a real portfolio loads all of it and tells me where it breaks.