The default objects encode assumptions. Most of them are wrong here.
Put a construction firm into a stock CRM configuration and you can watch the mismatch happen in real time.
Somebody asks a preconstruction lead to log an opportunity. The form wants an amount, a close date, and a stage. The lead hasn't decided whether the firm is even going to bid this. There's no amount, because nobody has estimated anything. There's no close date, because the owner hasn't published a schedule. And the stage picklist offers Qualification, Proposal, Negotiation, and Closed Won, none of which describe what's actually happening, which is that four senior people are going to sit in a room next Thursday and decide whether this project is worth chasing at all.
The lead enters a guess in every field, because the record won't save otherwise. Six months later somebody runs a pipeline report and the numbers are fiction.
This is not a configuration problem. The default CRM data model encodes assumptions about how selling works, and most of them are wrong here.
In most industries, pursuing a deal is close to free. You take the meeting. You send the proposal. Your marginal cost is somebody's afternoon.
In construction it is not free at all. Preparing a competitive response to a large project means estimators pricing the work, preconstruction staff building a schedule, sometimes design input, sometimes renderings, sometimes a full interview team rehearsing a presentation. That effort is real money and it comes out of overhead, not a project budget. A firm that chases everything will lose money doing it.
So firms hold a formal gate before any of that starts. Go or no-go. Do we know this owner, do we have the bonding capacity, is the schedule survivable, do we have a superintendent free, who else is bidding, and does the fee justify what it costs us to compete. It is a real meeting with real authority and it produces a real decision.
Standard CRM has no concept of this, because it assumes you want every deal in front of you. Construction firms decline most of what crosses the desk, and declining well is a genuine competency. A model where "no" is just a Closed Lost record is throwing away the most valuable decision the business makes.
It also means low win rates are not a problem to be fixed. On hard bid work, losing most of the time is the normal state of a healthy firm. Losing a project because someone underbid it is frequently the correct outcome. A CRM that treats every loss as a failure is misreading the business back at itself.
This is the part that decides whether any of it gets adopted, and it rarely makes it into a requirements document.
Most construction firms run some version of a seller-doer model. There is no dedicated sales team. The people winning work are the same people delivering it: project executives, principals, engineers, preconstruction leads. They are billable, or they are running active jobs, or both.
Every minute one of those people spends in a CRM is a minute not spent on a project that is currently paying the bills.
That is not resistance to change. That is a rational response to how they are measured.
Which means the usual playbook fails. You cannot solve this with training, and you cannot solve it by mandating data entry, because the person you are mandating has a superintendent calling them about a concrete pour. The only thing that works is making the tool cost them less time than it saves them, and the only way to know whether you have done that is to sit with them while they work.
Anyone designing for this industry who has not internalized that their users would rather be doing something else is going to build something nobody opens.
A firm may track a relationship with an owner, an architect, or a program manager for ten years before a specific project appears. The relationship is the durable asset. The pursuit is transient.
The stock model has this backwards. Accounts and contacts exist largely to support opportunities, which are the objects that carry value. Here it inverts. The pursuit is a temporary event that happens on top of a relationship that predates it and will outlive it.
And the parties are not arranged the way the model expects. A single project involves an owner, an architect, a construction manager, subcontractors, sometimes a joint venture partner. The same firm can be a competitor on one pursuit and a teammate on the next. A data model where an account is a customer cannot represent that cleanly, and forcing it produces records nobody trusts.
Standard opportunity math is amount plus close date. Booked, forecast, done.
A construction project awarded this quarter might bill over the following two or three years, and not evenly. Mobilization is slow. The middle is heavy. Closeout tapers and drags, with retainage sitting unbilled until the end. The shape of that curve varies by project type, by delivery method, and by how the contract was written.
Forecasting from amount and close date in that environment produces a number that is confidently wrong. What leadership needs to know is not what closed, it is what is going to bill in the third quarter of next year, which is a function of award date, project duration, and a distribution curve that has nothing to do with anything in the stock model.
Pipeline is a CRM's native output. Construction firms are managed on backlog: work under contract, not yet performed.
Backlog drives hiring. It drives equipment purchases, bonding capacity, and whether the firm can take on the next large pursuit at all. It is the number in the board deck and the number a lender asks about.
It is also not a pipeline report. Pipeline is what might happen. Backlog is what has been committed and not yet delivered. A system that reports beautifully on the first and cannot produce the second is answering a question nobody in the room asked.
None of this is an argument that Salesforce cannot serve construction. It serves it well. The argument is narrower and more practical.
The default objects carry assumptions: that you want every deal, that pursuing is cheap, that a loss is a failure, that revenue lands at close, that the account is the customer, and that your users are salespeople whose job is to be in the CRM. Every one of those is false in this industry, and none of them announce themselves during discovery. They show up as fields nobody fills in, reports leadership stops opening, and a system that quietly becomes a place where people record what already happened somewhere else.
If you are configuring for a construction firm and you have not asked how they decide what to chase, who does the chasing, and what number their board actually watches, you are going to build something technically competent that answers the wrong question.
That is not a construction problem. It is just unusually easy to see here.