The FF&E Matrix explained: what it is and how to use it

The FF&E Matrix is the document in a hotel's O&M handover that most closely resembles a usable database. While the Control Book gives a per-room-type view with product imagery and detailed specification, the FF&E Matrix gives the systematic view: every room, every category, every item in one structured document.

In practice, most operators find the Matrix hard to use. Understanding why it's structured the way it is — and what it would need to be genuinely useful — helps clarify both what to ask for at handover and what to build towards operationally.

What an FF&E Matrix contains

The Matrix is typically a spreadsheet or table, organised by room type along one axis and by FF&E category along the other. For each intersection — say, King Deluxe bedroom × Lounge Chair — the Matrix records the specification for that item in that room type.

A well-assembled Matrix will include, for each item:

• Manufacturer — the maker of the item
• Model name and reference — the specific product identifier
• Finish code — the specific finish, colour or fabric variant ordered
• Unit quantity — how many of this item per room
• Unit cost — the cost at time of specification (useful for budgeting; note it ages quickly)
• Supplier — who to contact for replacement
• Fire rating reference — the compliance certificate reference for regulated items
• Notes — any installation notes, maintenance requirements or important caveats

The Matrix may also include room count by category (how many King Deluxe rooms, how many Standard Doubles) so that bulk replacement quantities can be calculated directly.

How it differs from the Control Book

The Control Book and the FF&E Matrix serve different purposes and different users.

The Control Book is designed for identification: a facilities manager standing in a room, looking at a specific item, needs to know what it is. The Control Book is organised by room type, includes product imagery, and is designed to be read as a document. It answers "what is this?"

The Matrix is designed for inventory and planning: an operations director building a replacement budget or a procurement team planning a bulk order needs a systematic view across the whole property. The Matrix answers "how many of each item do we have, across which room types, at what specification?"

Neither document alone is sufficient. A hotel that has only the Control Book can identify items but can't easily calculate replacement quantities. A hotel that has only the Matrix has the inventory but not the identification.

Both should be part of the handover pack; in practice, the quality of each varies considerably between projects.

What makes a Matrix genuinely useful

The Matrix is only as useful as its data is current. Three things typically make it go stale:

Substitutions during procurement. When items are swapped during the procurement phase — a model discontinued between specification and delivery, a lead time that forced an alternative — the Matrix may not be updated to reflect what was actually installed. At handover, the Matrix describes the original specification; the rooms contain the procurement reality.

No update mechanism after handover. Like the Control Book, the Matrix is a point-in-time document. Each replacement that happens post-opening without updating the Matrix creates a divergence between the document and the building.

Cost data that ages. The unit costs recorded in the Matrix at specification become less useful as market prices move. A Matrix used for budget planning two years after specification will be working from outdated numbers for anything price-sensitive.

What a live Matrix looks like

A Matrix that's maintained as a live record rather than a static document overcomes all three problems. Substitutions during procurement update the record in real time. Post-opening replacements update the relevant rows. Pricing is refreshed against current supplier data when needed.

The practical difference is significant. A facilities manager who can query the current Matrix — not the handover-day Matrix — gets accurate replacement quantities, current supplier contacts and up-to-date specification data. A finance team modelling a refurbishment budget works from current pricing, not three-year-old figures.

Holding the Matrix as structured data rather than a PDF or spreadsheet is what enables this. A PDF Matrix can't be queried; a structured record can be searched, filtered and updated without creating a maintenance overhead that nobody does.

Controlbook treats the specification record as a live, queryable database from the start. If you want to see what that looks like for an existing property, book a demo or read about how we approached ingesting a real hotel's documentation.

Frequently asked questions

Should the FF&E Matrix include OS&E items?

Typically not. The FF&E Matrix covers durable FF&E — the items that appear in the design specification and are procured through the FF&E procurement process. OS&E (operating supplies and equipment) is managed separately. Including OS&E in the FF&E Matrix creates confusion about the different replacement cycles, budget lines and compliance requirements that apply to each category. They're better managed as separate documents.

Who is responsible for maintaining the Matrix after handover?

In a traditional setup, nobody — which is the root cause of why most Matrices are stale within two years. Making the Matrix a living document requires designating an owner (the facilities manager or director of engineering is the natural candidate) and building the update workflow into the maintenance and replacement process rather than treating it as a separate administrative task.

How do I reconcile a Matrix that doesn't match what's actually in the rooms?

This is the first step in building a live record from a static document. The reconciliation requires going through the Matrix row by row and verifying each entry against the current room state — either through a formal audit or through progressive updates as items come up for maintenance or replacement. Documenting each discrepancy and updating the record creates a current baseline. The goal isn't a perfect document; it's a document that improves steadily with each interaction.