Part of our series on the FF&E & OS&E procurement workflow. Start with the full workflow overview, or back up to Receiving, Inventory & Installation if you're starting further upstream.
A project can be delivered on time, on budget, and installed without incident — and still close out badly, in the sense that matters most to a procurement business: nobody involved learns anything from it. The specs get archived, the vendor relationships stay in someone's head, and the next project starts from close to zero. Closeout is the stage most FF&E and OS&E procurement teams underinvest in, not because it isn't valuable, but because by the time a project wraps, everyone is already three tasks into the next one.
The handoff package
The most immediate closeout task is practical: whoever is responsible for the space next — a project manager, an installer, the client directly — needs more than a delivery confirmation. They need the specs, the confirmed quantities, and whatever documentation came from vendors along the way: warranties, maintenance guides, installation instructions. When all of that lives connected to the actual spec and PO data it belongs to, it can be pulled together into a single handoff report. When it doesn't — when warranty PDFs are sitting in an email folder somewhere, disconnected from which line item they cover — closeout turns into a scavenger hunt, and the things most likely to get lost are exactly the things someone will need eighteen months later when a chair breaks and they're trying to figure out if it's still under warranty.
Budget vs. actuals.png)
By the time a project closes, there should be three numbers on the table for every category: what was estimated, what was quoted, and what was actually spent — including freight, duty, and any other landed cost, not just the unit price. If those three numbers were tracked in three different files throughout the project, reconstructing them accurately at the end is its own project. If they were tied to the same underlying spec data the whole time, the comparison is just a report.
This is also where a realistic sense of estimating accuracy comes from. It's normal for a preliminary budget — built before a single vendor has actually quoted anything — to land somewhere in the range of 7–12% off from the final confirmed cost once everything is factored in, and that variance can run higher depending on the region and category. That's not a failure of the estimate; it's the nature of estimating before sourcing is complete. But a firm that tracks this project over project can tighten that range over time, because they're comparing against their own real history instead of guessing fresh each time.
Vendor performance and lessons learned

The data worth keeping on a vendor isn't just "we ordered from them" — it's on-time delivery against the lead time they quoted, how their pricing held up against the market, how responsive they were when something went wrong, and whether shipments matched what was ordered without shortages or damage. None of this requires a formal scorecard system to be useful; it just requires the data to be there, attached to the vendor, across every project rather than starting a fresh impression each time. That combination of memory and data is what actually improves vendor selection on the next project — versus institutional memory alone, which (fairly or not) tends to remember the one bad experience far more vividly than the ten uneventful ones.
The same logic applies to internal process, not just vendors: which categories consistently ran over budget, which approval steps consistently caused delays, which templates or workflows needed the most rework. Reviewing that phase by phase after a project closes — not just the vendor list, but the internal process too — is how a firm's own playbook actually improves project over project, rather than staying static.
Cross-project reporting and negotiating leverage
Individually, most projects don't represent enough volume with a single vendor to justify asking for a better rate. Aggregated across a year or two of projects, they often do. A cross-project view — total spend, total quantity, and current open orders with a given vendor, across every project a firm has run — turns "we'd like a discount" into "we've purchased $X from you across Y projects," which is a fundamentally different conversation. This is also the practical reason procurement firms benefit from keeping data in one system rather than one spreadsheet per project: the leverage only exists if someone can actually see it, and a filing cabinet of closed-out project folders doesn't let anyone see it.
Markup, margin, and what "profitable" actually means

Procurement businesses in this space tend to make money one of a few ways: a flat or percentage-based procurement fee (a flat fee in the neighborhood of 4% of purchase volume is common for pure sourcing services), a cut of the discount negotiated from list price, or a markup on the goods themselves, typically targeting a gross margin somewhere around 30% as a general benchmark — though this varies by firm, region, and scope of services. Whichever model applies, the number worth tracking closely is target margin versus realized margin, project by project, because that gap is where inefficiency (or a badly scoped project) actually shows up.
Worth being direct about this too: time is part of the real return, not a side note. A project that nets a firm the same total profit as another but takes twice as long to close is not an equally good outcome — the cost of keeping staff and overhead running for those extra months is real, even if it never shows up as a line item on the project itself. Tracking margin without also tracking how long it took to earn it gives an incomplete picture of which projects were actually worth taking on.
One honest limitation worth flagging: a tool like Fohlio can hold the budget, cost, and margin data needed to do this analysis — target margin against real numbers, project by project, historically — but it doesn't calculate ROI or profitability for you automatically. That comparison is still something a firm has to do deliberately, using the data the system makes available, rather than something that happens in the background on its own.
Change orders

Worth naming plainly here too: when a price shifts, a quantity changes, or a vendor substitutes a product after a PO has already gone out, most procurement tools — Fohlio included, as of today — don't have a dedicated change-order workflow. The common workaround is closing the original PO and issuing a new one, which gets the job done but leaves the "why did this change" context to be tracked separately, usually back in whatever system captured the original approval. Worth knowing going in, rather than assuming otherwise.
The historical product database

Every specified and purchased item — with its real cost, its vendor, and how it actually performed — is worth keeping searchable, not just archived. How much this gets used tends to depend on the type of work: firms doing a lot of standardized, builder-grade work lean on it constantly, since a large share of what they specify is genuinely repeatable. Firms doing bespoke, high-end work use it differently — not as a shortcut past custom design, but as an accumulated record of which manufacturers and materials have actually been reliable, on projects that were never meant to be identical to each other. Either way, the next spec doesn't have to start from a blank search if the last one's data was kept.
Where AI actually fits in

There's an obvious temptation to describe every part of this process as something AI will soon automate outright. The more accurate version: AI assistance is genuinely useful for the search-and-synthesis parts of this work — finding information faster, getting a second opinion on how to approach a task, drafting something that would otherwise take longer by hand — provided it's built with real controls around customer data, since vendor pricing, client budgets, and project details are proprietary information that firms have every reason to keep private. It's a real productivity layer on top of the workflow, not a replacement for the judgment calls procurement teams make daily.
For more on AI in Interior Design, read:
Building an AI-Ready Design Practice,
How AI Is Reshaping Interior Design Specifications, and
Why AI Fails in Interior Design Without Structured Data.
Improving the next project
None of the individual pieces here — budget accuracy, vendor performance, margin tracking, a searchable product history — are complicated on their own. What makes them valuable is that they compound, project over project, if the underlying data was kept connected in the first place. That's really the argument threaded through this entire series: the firms with the smoothest projects aren't working harder than everyone else. They've just stopped losing the data that would have made the next project easier than the last one.
If it'd help to talk through your specific setup, we offer a free workflow assessment — no pressure, just a look at where the gaps are.
Catch up on the rest of the series:
If you run procurement for a portfolio of projects, or work with procurement teams who do, and think this would be useful to your network, we'd appreciate a share — or browse the rest of our blog for more like it.