Why construction companies keep using Excel for estimation
Ask an estimator at a mid-sized construction company to describe their workflow and you will hear the same story: a base file in Excel, supplemented with figures from experience, adjusted based on the last project that went wrong. That is not laziness or a lack of ambition. It is a rational response to packages that are too generic. Standard construction ERP systems come with modules for everything: procurement, invoicing, workforce planning, time registration. But the estimation logic a structural contractor needs differs fundamentally from what a mechanical installer or finishing specialist requires. A package that does everything does nothing precisely enough. The Excel file therefore stays alongside the package, not instead of it.
What goes wrong when estimation and planning exist in isolation?
Estimation determines the materials list and the deployment of people. Planning determines when, who, and where. When those two do not communicate, a classic problem emerges: the site manager receives a schedule built on assumptions the estimator made three months ago, with no access to current material prices or team availability. That leads to last-minute orders, standstill on site, and a post-project analysis no one wants to look at. Construction growth in 2026 is expected to be limited, at 0.2% according to Rabobank forecasts. In a market with tight margins, that is precisely the kind of loss that determines whether a project delivers a return or leaves you writing a cheque.
When is a standard package good enough and when is it not?
A standard construction software package works well when your business processes are close to the standard: a fixed crew size, limited variation in project types, little customisation in execution. For civil engineering contractors, specialist subcontractors, or builders who combine new construction with maintenance and service work, things break down quickly. The reason is straightforward: the package is built around the most common way of working, not around your way of working. Customisation is possible, but bespoke modifications to a standard package are expensive, fragile under updates, and create dependency on the vendor. Once you are spending more time maintaining the customisation than you gain from the automation, the calculation turns negative.
What does work: domain-specific systems and AI support
Construction companies that move to a system built around their own estimation logic and planning rhythm notice the difference immediately in day-to-day operations. Estimation rules are defined once and reused. Enquiries for new work are assessed faster because historical project data is directly available. Planning changes are pushed through to the materials procurement list without a second employee having to intervene. That is not AI magic: it is the result of a system built on the actual workflow, not on a generic process diagram. For companies looking to replace their core system, the Bonsai AI Digital Twin is the approach: a fully new, domain-specific system that goes live within months. For companies that want to keep their existing package but add an intelligent layer around it, Bonsai AI Workers are the route: they take over the manual data entry without touching the existing system.
How do you get started without launching a large digitalisation project?
Most construction companies do not switch to a new system because they are wary of the process involved. Rightly so: implementations of standard packages regularly overrun and cost more than budgeted. The key is to start small with high impact. Identify the process where the most time is lost to manual re-entry or double input: is it the estimation itself, the conversion of an estimate into a work order, or feeding time registration back into post-project analysis? Start there. Build a solution that handles exactly that one process, get it into production, and only then build further. This avoids the big-bang risk and builds confidence across the operation.