What we learned ingesting 534 FF&E specs from a real hotel

Building a platform to digitise hotel FF&E records is one thing. Actually running a real O&M manual through it — one that came from a live hotel project, assembled by a real design firm, in the formats that actually exist in the industry — is something else.

We ran the full handover documentation from a 314-room Holiday Inn property through our ingestion pipeline. The project reference is 23051; the documentation covered 534 individual FF&E specifications. Here's what we found.

What the documentation actually looked like

The handover pack for this property included four types of document, which matches the standard format used by most design firms and procurement companies:

FF&E Matrices. Spreadsheet-style documents listing every item by room type: manufacturer, model, code, finish, fabric reference, quantity per room, and supplier. These contain the most structured data and are the most amenable to programmatic parsing.

Control Books. Per-room-type spec sheets, typically including product imagery alongside the specification text. These are the documents a facilities manager is most likely to reach for when they need to identify a specific item. They combine structured product data with design imagery, which makes them more useful operationally — but also more complex to process automatically. Vision-based extraction is needed to handle the image-heavy pages.

Type Schedules. Summaries of room types and their FF&E contents, useful for understanding the overall inventory structure rather than the detailed specification of any individual item.

Drawing Registers. Reference documents mapping FF&E items to the architectural drawings, useful for installation and spatial context.

Each document type requires different handling. The FF&E Matrix can be parsed with relatively straightforward table extraction. Control Books need a combination of text parsing and image recognition. Drawing Registers are primarily useful as cross-references rather than as standalone data sources.

What the variety problem looks like in practice

Across the industry, there is no standard for what an O&M manual looks like. Two design firms working on comparable hotel projects will produce documentation in substantially different formats — different column headers, different naming conventions, different ways of recording fabric references or compliance certificates.

Even within a single project, the format can shift between document sections as different team members assembled different parts of the pack. A fabric reference might appear as "Ref: FW-204/A" in one section and "FW204A" in another. A manufacturer might be listed as a full legal name in one document and a common trade name in another.

This is not a criticism of the design industry. These documents weren't designed for machine ingestion — they were designed to be read by human beings with knowledge of the project. The challenge of digitisation is translating from that format to something a database can store and a search function can query.

Our pipeline now handles the main document types encountered in the industry. Budget significant manual review time for early onboardings: the target is thorough field coverage, and reaching it requires human verification of the automated extraction, particularly for the more complex document sections.

What structured data enables that a PDF doesn't

Once the 534 specifications from this property are held as structured data rather than as document pages, the change in what's possible is significant.

A facilities manager can type the room number — say, room 214 — and see every item in that room, with its manufacturer, model, finish, supplier and fire rating. They don't need to know which Control Book to open or which section it's in. The query works regardless of how the item was formatted in the original document.

A search for "discontinued items" returns every specification where the manufacturer has retired the model — which, across a 314-room property that opened several years ago, is a meaningful list. Knowing that list in advance of a failure is operationally different from discovering an item is discontinued in the moment you need to replace it.

A replacement workflow can pull the original specification automatically when a fault is reported, so the person handling the replacement order starts with the correct details rather than beginning a search.

None of these things are possible from a PDF. They become basic operations once the data is structured.

What this changed for how we approach ingestion

Working with real documentation from a real hotel sharpened our understanding of where the process needs human judgment and where it can be automated confidently.

The most consistent challenge isn't the document type — it's the gap between what the document contains and what an operator actually needs. A Control Book records the specification as it was at handover. It doesn't record which items have been replaced since then, which suppliers are no longer active, or which finishes have been discontinued. The document is the starting point for a live record, not the live record itself.

That's the ongoing work: not just ingesting the original documentation, but building a workflow where every replacement and every change updates the live record, so the specification stays accurate over the life of the asset.

If you're thinking about how this applies to your property — whether you have an existing O&M pack or are approaching a new fit-out — book a demo and we'll walk through what the ingestion process looks like on your documentation. Or read more about the hotel FF&E lifecycle for context on where ingestion fits in the longer arc.

Frequently asked questions

How long does the ingestion process take for a hotel of this size?

The automated extraction runs quickly. The manual review and verification — confirming that key fields have been captured correctly and flagging anything that needs human interpretation — is what takes time, and varies significantly with document quality. Well-structured, programmatic PDFs are faster to process than scanned documents or those with non-standard formatting. Budget time accordingly for early onboardings.

What happens if the original O&M manual is incomplete?

Incomplete documentation is common. Some items are well-documented; others have minimal specification. Where fields are missing, the record reflects that gap rather than inventing data. The resulting record is still useful — knowing which items are well-specified and which aren't is itself valuable operational information.

Can we add documentation from multiple refurbishment phases?

Yes. Properties that have undergone partial refurbishments can have multiple documentation sets — the original and any subsequent updates. Merging those into a single live record, with the most recent specification taking precedence for each item, is the right outcome. It requires care to ensure that original and replacement items are correctly distinguished, but it's straightforward once the data is structured.