The system of record was there. Filling it was manual, and the drawings were unreadable.

Our client sells a knowledge and compliance platform to facilities teams: the place a technician goes for operational information. Two things limited it. Getting a new customer’s data into it was manual, site by site. And the building drawings that describe much of a site could be stored, but never answered from. Focaloid built the AI workflows for both.

01The client sells the software

The client is the system a technician opens when they need to know what a piece of equipment is and how to work on it. It runs no buildings of its own. Its customers do: a facilities-management firm signs, and arrives with a portfolio of sites. Every site has to be loaded into the platform before anyone gets a single answer out of it.

Take a representative site: a 420,000 sq ft distribution centre. A plant room of air handling units, a chiller and a boiler; switchboards and a transformer; a wet riser and a fire pump; eight dock positions; five racking runs; conveyors and charging bays. Each one is an asset with a record in the platform: what it is, where it is, who made it, when it was last serviced, the manual and the procedure. That part the client had already built. What was left were two questions: how the record gets filled, and how much of it a system can actually answer from.

1. Asset
2. Record in the platform
3. Technician opens it

02Two problems, multiplied by a portfolio

Problem one: the record was filled in by hand

A customer arrives with a spreadsheet export from whatever maintenance system they were using. Their column names, not the platform’s. The same air handling unit entered twice under two spellings. Locations as free text: “B2 East Wing” in one row, “Basement 2 - East” in the next. OEM missing on a third of the rows. Someone at the client read it line by line and decided what each row meant before any of it could be loaded. Nothing was missing from the product; getting data into it was the bottleneck.

1. Their export
2. Read line by line
3. Into the platform

Problem two: a drawing is written for a person to read

Much of the site exists only as plan sets (mechanical, electrical, plumbing, fire), usually PDFs, sometimes scans of them. The equipment is on them as symbols with tags beside them, and the schedule in the corner carries the make, the model and the duty. The platform could already hold that drawing: a technician could open it and read it. What no system could do was answer a question from it. So someone read the plans and re-typed the metadata: the slowest part of every onboarding.

Linking the documents was hand work too

OEM manuals, warranty certificates, lock-off procedures, inspection records, service notes scanned from paper. The platform holds documents against assets, but somebody has to decide which document belongs to which asset, and somebody has to notice the ones the customer never supplied and go and find them. Across a portfolio that is a great deal of deciding, and whatever got missed turned up later as an asset with no manual.

The limit was never access. It was how complete the record was, and how much of it was structured enough to answer from.

At the unit, the technician gets what was put into the platform. If the unit only ever appeared on a drawing, there is no record to open, just a plan set to scroll through; and a 212-page manual is still a document to read, not an answer. Now multiply the first problem by a portfolio. One site is a slow week. A customer signing with a portfolio is that week repeated per site, done by the client’s own staff, before the customer sees any value at all. Onboarding capacity became the limit on how fast the client could sell.

03What we built

Those are the two problems we were asked to work on: the manual preparation, and the drawings no system could read. Four things changed.

The data entry becomes a review step

The export is read as it arrives. Columns are matched to the platform’s own fields with a confidence score, values are normalised, duplicates are detected and merged, and missing fields are flagged rather than quietly left blank. A person now reviews the mapping once instead of typing it, approving decisions rather than making them, and the same mapping is reused for the rest of that customer’s sites.

The drawings become something a system can read

Plan sets are parsed directly. Room boundaries and zones are detected, equipment symbols are classified against the legend, asset tags are read, the schedule in the corner is extracted as a table, and each symbol’s position on the sheet becomes a location on the site. A drawing a person used to read becomes data the platform can answer from. Equipment that existed only on a plan now has a record, and conflicts (a tag used twice, a symbol with no label) are raised for review rather than invented.

1. Plan set
2. Symbols and schedule
3. Structured, queryable records

The linking, and the chasing, stop being manual

Documents are classified on upload (manual, procedure, warranty, service record) and matched to assets with a confidence score instead of by hand. The register is then checked for coverage, and the assets with no manual are the ones worth chasing: those are searched for on the manufacturer’s own site and linked when found. What is still missing stays visible as a gap rather than being discovered by a technician at the unit.

1. Classify
2. Match to asset
3. Fill the gaps
4. Coverage you can see

So the record can be asked, not just opened

The same record the technician always had, now complete enough and structured enough to answer a question put to it in plain language: what is this, what happened last time, what does the manual say about this job, what has to be isolated first. The answer comes back as the part that matters, not the 212-page document, and it can cover equipment that used to exist only as a symbol on a drawing. What they find is logged back against the asset.

04The same site, before and after

Switch between the three states. Before, the register held what the customer’s export happened to carry and what someone had typed in. After, the drawings and the document libraries have been read as well, with the same human effort, spent reviewing rather than typing.

05What the client reported

Across the client’s onboarding, its technicians and its own customers, this is what the client reported.

As reported by the client. The site, names, counts and documents shown elsewhere on this page are representative and fictional.

06Where to start

If your product only becomes useful after someone manually prepares a customer’s data, that preparation is your growth ceiling, and anything your customers hold as drawings or scans sits outside what your system can answer from.

We usually start with one real customer dataset: an export, a plan set and a folder of documents, and show what comes out the other side.

A representative customer and site. Names, counts and documents are fictional; the client is not named. Outcome figures are as reported by the client.