Construction ERP Customisation: What Contractors Lose While Waiting for One Feature

Construction ERP customisation refers to changes or additions to features beyond what is generally offered in the product. Configuration means adjusting existing settings, such as approvals, roles, units of measurement, and report filters, according to how your company works. Most requests that reach us during onboarding fall into one of these two categories. The difference between customization and configuration determines whether a request takes two days or two months to resolve.

Why Does Pausing Onboarding for Construction ERP Customisation Cost More Than the Customisation Itself?
Customization can take time, sometimes weeks or months. During that period, the subscription continues. However, the site team may still move back to WhatsApp or Excel, and each record that should have been in the system shifts back to the old ways and is lost from the system permanently. The momentum of onboarding fades. The team may need retraining when the customization eventually arrives, and the process that should have taken less time ends up starting all over again.

In Pune, a contractor was onboarding the software for three weeks. When the point of contact raised a request, they needed to add an Arabic output to match the Excel format exactly because the team had been using that format for almost four years. They needed the same column order, heading labels, and row grouping. Until that was delivered, they refused to move forward.

The request was valid because the team had spent years working with that billing process on that sheet, and presenting a different format to a client was going to require an explanation. However, the onboarding process stopped because of the request. The problem was the decision to treat that format as a condition for going live.

That condition held back three weeks of progress, a trained team, and a live project from producing any value. In our experience onboarding contractors across India, the software itself is rarely the problem. The problem occurs when onboarding is stopped while waiting for a customization. In most cases, the cost of stopping the onboarding is greater than the value of the customization itself.

Construction ERP Customisation Requests We Hear During Onboarding

There are multiple ranges of requests that we receive while onboarding. At one end are small requests, such as an extra column in a report, a renamed field, or a changed label on a document. These are often resolved quickly within the existing configuration settings, sometimes during a short call.

However, there is a larger category of requests for features that do not exist in the product, such as a custom integration with a specific accounting tool, a new approval chain with different logic, or a billing format with calculation rules that differ from the standard.

One of the requests we encounter most often is that the RA bill must match the client’s Excel format exactly. This is one of the most common billing-related requests we receive. The difference between requests can be as small as changing column sequences or heading labels. Sometimes, the client has genuinely unique billing logic. Both types of requests can end up being treated as conditions for going live.

Another common request is, “We need a report that shows all active vendor balances across all projects, filtered by category.” This is also one of the frequently asked configuration requests rather than a customization. The data already exists in the system, but what is required is a specific combination of filters.

Another request is, “When a GRN is approved, the system should automatically send a WhatsApp message to a site engineer and project owner.” This is one of the more common customization requests. It falls under an automation workflow and is a genuine customization request.

The pattern is consistent. Both small and large requests can end up being presented as conditions for continuing the onboarding process.

Why Contractors Want to Customise Before Going Live

The reasoning behind customization requests is usually understandable, and we try to approach them that way. 

Our process is different: Every contractor believes that their process is different. They believe this when it comes to billing formats, approval chains, or site reporting structures. In the majority of cases, the difference is in the details. They are often correct about that, but they can be wrong about the extent of the difference. The underlying process of raising a request, getting approval, procuring and receiving the material, and certifying it remains consistent across the industry. What varies is the surface format.

The system needs to look like the old Excel sheet: Wanting to have the same format as the old Excel sheet is more about comfort than functionality. A team that has spent years working with the same Excel sheet may find a different layout disorienting, even when the data is identical. The POC advocates for the familiar format before going live so that the site team does not push back on day one.

A bad experience with earlier software: Many contractors arrive with a specific concern: they have gone live with something that did not fit their process, it failed, and they now want to resolve every process gap they faced before committing again. It is a very genuine thing to do. However, the timing creates a new problem.

The POC’s preference standing in for company needs: A POC is a person who handles all the old Excel system data. They often request the same format they have been using, something they created themselves rather than a company-wide requirement. When the POC pauses onboarding for a format preference, the broader team typically does not know that the system is waiting.

Configuration Versus Customisation: What Most ERP Requests Actually Need

A number of requests can be resolved without any development work. They can be handled using configuration tools that are already available in the platform.

There is an approval workflow in Onsite that can be configured by role and department. Any contractor who wants a three-level purchase order approval process involving the site engineer, project manager, and director does not need to get the system customised. It can be configured.

Report filters can be set by project, site, material category, vendor, and date range. Any contractor who asks for a custom report may not actually need a customization. It can often be achieved through a combination of filters that already exists in the system.

User roles and permission controls determine who can see what within the company. A contractor who wants the site engineer to see only their own site’s materials and tasks, while the owner can see everything across the project, is also looking at a configuration rather than a customization.

Units of measurement, field labels, and document names can all be adjusted within the system. A contractor who, for example, wants to use “Running Bill” rather than “RA Bill” can change this as part of the setup process.

A request can genuinely fall outside these options. Examples include a billing format with unique calculation logic, an integration with an unsupported accounting tool, or a module that does not exist in the product. These are considered customizations. They require time and a separate commercial discussion.

Before raising any request as a condition for going live, we recommend checking with the onboarding team whether it can be resolved through the existing settings.

When Construction ERP Customisation Is Available but Clients Still Hold Back

When a genuine customization request comes in, it does require development work and cannot be resolved through configuration alone. In those cases, we scope the requirement and offer to build it as part of an enterprise engagement.

There are two things in this case that can extend the pause in onboarding.

The first is that the client declines to pay for the scope. We have a clear customization policy where standard configuration is included in onboarding. However, customization involves development work, adding features or formats that do not exist in the standard product. It is available only on enterprise plans, with charges based on the scope of the requirement. Any details about this are available on the Onsite pricing page.

There are many clients who want custom features but are not ready to pay for the time and effort being spent on development. The result is an impasse. The feature remains unbuilt, and the client still treats it as a condition for going live.

The second is that the client refuses an interim workflow. An interim workflow means running the process using the standard setup while the customization is being built. Meanwhile, the customization development continues, while the onboarding and usage of the software also move forward.

However, some clients refuse to do this. The RA bill goes out in the standard format while the custom format is still in development. The approval chain uses the standard logic while the more complex version is being scoped. The system is live and producing value, and the customization arrives later.

Clients who refuse to move forward with this approach take an all-or-nothing position. The system should either run exactly how they want it to, or they do not want to run it at all. This basically results in nothing being run.

The subscription, training investment, and onboarding work sit idle while the impasse continues.

What Pausing Construction ERP Onboarding Actually Costs

This is one of the most frequently discussed issues with clients, and it is also the easiest part to underestimate. The subscription continues during the pause.

Any contractor who is running 10 users on a business plan pays approximately ₹10,000 per month on an annual plan. A three-month pause means ₹30,000 paid with no operational value received. If the pause continues for another three months, the cost doubles.

For a company that has gone through the demo process, committed to the platform, and signed a subscription, this money is being spent on a system that has not yet run a single project. However, the subscription cost is actually the smaller part of the problem.

Each month that passes without your project being run in the system is a month of project data that will never be captured. Materials are moving in and out of the project site without being recorded and verified in the system. Labour records are being maintained in physical registers. RA bills are being prepared in the old Excel format. Everything goes back to the way it was.

Progress updates are shared on WhatsApp, and vendor payments are approved without a procurement record to reconcile against. This is something that cannot be recovered. The system that goes live after a six-month pause has no project history to inherit from the six months that have been lost.

Broader research on ERP implementation outcomes reflects a similar pattern. Panorama Consulting’s 2025 ERP report puts the overall implementation failure rate at 68%, with inadequate change management and delays during implementation among the top causes of failure. A customization debate that stalls onboarding is, in microcosm, the same failure in progress: a process question that was not resolved before it became a reason to stop moving.

How to Handle Construction ERP Customisation Without Stopping Onboarding

We apply a principle in every onboarding where a customization request comes up: separate what you eventually want the system to do from what needs to be true for the system to run today.

Classify requests before presenting them as conditions: Before treating a request as an immediate requirement and a reason to pause, you need to identify whether it is a must-have or a preference. A must-have is something that can actually pause the process and may be genuinely necessary to run the project. A preference, however, is a choice about how you want to run the process. In practice, most requests that arrive as conditions for going live turn out to be preferences when examined closely.

Decide quickly whether the customisation is worth the commercial scope: If a request falls under our enterprise customization policy, the decision to proceed or not should be made within days. A request that is not worth paying for should not pause onboarding while the debate continues.

Accept an interim workflow and keep moving: If you are being asked to run an RA bill in the standard format for at least 60 days, it is not a compromise. It is a decision to capture 60 days of data related to material requests, vendor payments, billing records, and site progress, which would have been permanently lost if they were not recorded. The custom format may arrive later, but the project records cannot be retrieved.

Raise remaining requests after thirty to sixty days of real usage: Clients who rush to go live before putting all their requests on the table consistently discover that several requests they planned to make are not relevant after seeing how the system actually works. Real usage clarifies real gaps. Anticipated gaps are often different from the actual ones.

Along with eight customization requests, a mid-sized contractor in Maharashtra came to us and shared their customization requirements. Three of the requests were presented as conditions for going live. As part of the normal process, we agreed on interim workflows for all three and completed the onboarding within the original window. Four weeks into using the software, they withdrew two of the three conditions. They discovered that the standard formats available in the software were already working well and that the custom versions were no longer needed. The third customization was built in the next release cycle. By the third week, they had discovered that the system was already delivering more value than they had expected before any customization was built.

Conclusion

Construction ERP customization is a genuine need for some construction companies. Systems that do not align with a company’s processes can be inconvenient. However, the most common problem we see across the onboarding cycle is not that contractors want customization. It is that contractors stop everything while waiting for the customization.

The cost of that pause is not small. It can be bigger than the cost of the software itself because all the data that goes missing during the period when onboarding is paused is lost and provides no value. There is no system to track it back.

Before pausing onboarding for any customization request, ask one question: Can this process run on

Frequently Asked Questions