CRM for Contractors: How to Choose and Configure One for a Contracting Business
CRM for contractors: why a bid is not a deal, which objects a contracting business needs, and where the CRM must stop so project management can start.
Paul Maxwell, PhD
AUTHOR
GET WEEKLY REVOPS INSIGHTS
No spam. Unsubscribe anytime.
A contractor installs a CRM, maps bids onto the deal object, and within two quarters the pipeline report is unusable. Win rate reads at nineteen percent and nobody knows whether that is good. Half the open deals passed their decision date months ago and sit there because no salesperson closes a bid they did not lose so much as never hear about again. Two records exist for the same building because it was bid once through a general contractor and once direct. The forecast is a number nobody defends in a meeting.
None of that is a configuration mistake in the ordinary sense. It follows from mapping a bid onto an object designed for a deal, and the two behave differently in four specific ways this article sets out.
The article covers what a contracting business needs from a CRM and how to configure one. It begins with how a bid differs from a deal, then models the bid as its own object with the fields that difference requires. It then addresses the same job arriving through several routes, which is the problem that produces duplicate records and double-counted pipeline. From there it covers the boundary with project management software, change orders and what they do to revenue reporting, and the estimating handoff. Configuration requirements follow, then how those requirements differ by contractor type, then the antipatterns and the checks worth running against an existing setup.
Four Differences Between a Bid and a Deal
A bid is awarded, not closed. The decision belongs to somebody else and is made on a date they set. A sales pipeline models a deal the seller is steering toward a close; a bid is submitted and then waited on, and the difference matters because pipeline stages that describe seller activity have nothing to describe after submission.
The decision date is external and frequently slips. A close date a salesperson sets is a forecast; a bid decision date is a fact about somebody else's process, and it moves for reasons the contractor never learns. A pipeline that treats the two identically produces a forecast that is confidently wrong.
Low win rates are normal. A contractor winning one bid in five is often performing well. A CRM configured with a sales team's assumptions will flag that as a problem, and the correction applied — bid more, qualify less — is usually the wrong one.
The bid is priced from a takeoff, not negotiated. The number comes from an estimate against drawings and quantities. What is negotiable afterwards is scope and terms rather than price, which inverts how a standard pipeline models the late stages.
Those four are why bid pipeline stages need designing rather than adopting, and why separating an award from a win turns out to be the load-bearing distinction in practice.
The Bid as an Object
Whether implemented as a deal with contractor-specific properties or as a custom object, a bid needs fields a sales deal does not.
The project, distinct from the customer. A general contractor is the customer; the hospital is the project. Both matter, and conflating them is what makes the same job appear twice.
Bid due date and decision date, as separate fields. The first is the contractor's deadline, the second is the awarding party's, and only the first is under anybody's control.
Delivery method — hard bid, design-build, negotiated, CM at risk — because it determines what the pursuit actually involves and who the competition is.
Estimated value and estimated hours or units, since a bid's size in revenue and its size in capacity are different numbers and the second is what constrains the business.
Outcome with a reason. Won, lost, no-bid, withdrawn, no decision. Losing on price, on schedule, on bonding capacity and on prequalification call for four different responses, and without the reason every loss is attributed to price.
Bid-to-award interval, derived rather than entered, because it is the measurement that makes capacity planning possible.
The Same Job, Arriving Twice
The duplicate problem in contracting is structural rather than a data hygiene failure, which is why deduplication tools do not fix it.
A single project reaches a subcontractor through several routes simultaneously: an invitation from two competing general contractors, a plan room listing, and occasionally the owner directly. Those are three or four legitimate pursuit records for one building, and they are not duplicates in the sense that merging them would help.
They also must not be summed. A pipeline counting all four at full value forecasts four times the revenue available, and a contractor with a large plan room presence can inflate an entire quarter this way without anybody making a mistake.
The configuration that resolves it separates the project from the pursuit. One project record, several pursuit records pointing at it, and pipeline value reported at project level with the best-case pursuit rather than the sum. That is a modelling decision taken before records accumulate, and retrofitting it means reconstructing which historical bids were the same building.
The Boundary With Project Management
Most contractors already run Procore, Buildertrend, ServiceTitan, Sage or an equivalent, and those systems own the job once it is awarded: schedule, submittals, RFIs, cost codes, labour and billing.
A CRM introduced alongside them must be told where to stop, and the boundary that works is the award. Before the award, the CRM owns everything: the relationship, the pursuit, the estimate and the decision. After the award, project management owns the job and the CRM holds a reference to it. One direction of sync, from project management back into the CRM, so revenue and margin outcomes can be read against the bids that produced them.
The recurring error is a CRM that grows into project management because somebody added a task list. It does not have the scheduling, the cost codes or the field access, and the two systems begin disagreeing about job status in front of customers.
Change Orders
A change order is where a contracting business earns or loses the margin the bid was meant to protect, and it is almost never in the CRM.
The reason is organisational: change orders are raised in the field or by the project team, in the project management system, after the CRM's involvement has nominally ended. The consequence is that the contract value in the CRM is the original award, the actual value is materially different, and every report comparing bid to outcome is comparing the wrong number.
The minimum that fixes it is a single field on the project record holding current contract value, updated from the project management system, alongside the original award. The gap between the two is one of the more informative numbers a contractor can produce and is covered further in change orders between HubSpot and a construction management system.
Estimating and the Handoff
Estimating capacity is the constraint most contractors actually operate under, and a CRM that models only revenue cannot see it.
Two bids worth the same revenue can differ by a factor of five in estimating hours, so a pipeline sorted by value will route effort to the wrong pursuits. Recording estimated takeoff hours alongside value makes the go/no-go decision visible, and it makes the no-bid a deliberate act rather than a deadline quietly missed.
The handoff to estimating is also the point where a workflow earns its place: an invitation arrives, the go/no-go is recorded with a reason, and the pursuit either enters estimating with a named owner and a due date or is closed as a no-bid with the reason kept. Contractors who record no-bids can answer why they did not pursue a customer's last three projects, and contractors who do not, cannot.
Configuration Requirements
- Project separate from pursuit, with pipeline value reported at project level.
- Decision date distinct from bid due date, and reporting that distinguishes stale from lost.
- Outcome reasons including no-bid and no-decision, not just won and lost.
- Estimating hours alongside value, so capacity is visible.
- Award boundary to project management, one-way sync back for outcomes.
- Current contract value against original award, so change orders reach reporting.
- [Quotes or proposals](https://knowledge.hubspot.com/quotes/use-quotes) with an expiry, because a bid held open indefinitely is priced against superseded costs.
Requirements by Contractor Type
| General contractor | Specialty subcontractor | Service and maintenance | Residential | |
|---|---|---|---|---|
| Pursuit source | General contractorOwners, developers, plan rooms | Specialty subcontractorInvitations from several GCs | Service and maintenanceExisting customers, referrals | ResidentialHomeowners, referrals |
| Duplicate risk | General contractorLow | Specialty subcontractor**High — same job, many routes** | Service and maintenanceLow | ResidentialLow |
| Bid volume | General contractorLower, larger | Specialty subcontractor**High, smaller** | Service and maintenanceContinuous small quotes | ResidentialModerate |
| Binding constraint | General contractorPrequalification and bonding | Specialty subcontractorEstimating capacity | Service and maintenanceDispatch and scheduling | ResidentialLead response time |
| CRM emphasis | General contractorRelationship and prequal history | Specialty subcontractorBid throughput and no-bid discipline | Service and maintenanceRecurring service agreements | ResidentialSpeed to first contact |
The second column is the one general CRM guidance serves worst, and it is the largest population.
Antipatterns
Bids as deals with default stages. Stages describing seller activity, which stops at submission.
Summing every pursuit on one project. Forecasts several times the available revenue, with no individual record wrong.
No no-bid record. The decision not to pursue is the most common decision made and the least often recorded.
Win rate measured without delivery method. Hard bid and negotiated work have different normal win rates, and averaging them produces a number that describes nothing.
The CRM growing into project management. It lacks scheduling, cost codes and field access, and the two systems disagree about job status publicly.
Contract value frozen at award. Every bid-to-outcome comparison uses the wrong number.
Verification Before Buying or Reconfiguring
- Duplicate audit. How many open pursuits point at the same physical project, and whether the pipeline sums them.
- Stale pipeline. What proportion of open pursuits passed their decision date, which measures whether outcomes are being recorded at all.
- No-bid rate. Whether it is recorded. If it is not, the pursuit data describes only what was chased.
- Win rate by delivery method, not in aggregate.
- Award-to-outcome linkage. Whether a won bid can be traced to the job's final margin without a manual lookup.
A contractor who cannot produce the first two has found the reason the pipeline report is not trusted, before any software decision is made.
Boundaries of This Article
This covers requirements and configuration rather than ranking products, which is a separate question treated on its own terms.
Project management systems are treated as a boundary rather than reviewed. Which of them suits a contractor is generally the more consequential decision and turns on trade, project size and existing accounting.
Bonding, prequalification and lien requirements vary by jurisdiction and by owner. They are named here as constraints that belong on the record; their specifics are a question for the contractor's own surety and counsel.
In Summary
A bid is awarded rather than closed, on a date somebody else controls, at a win rate that is normal at levels a sales team would treat as failure, from a price produced by a takeoff rather than a negotiation. A CRM configured as though bids were deals will misreport all four.
The modelling decisions that matter are separating the project from the pursuit so the same building arriving through three routes is not counted three times, recording outcome reasons including the no-bid, holding estimating hours alongside value so capacity is visible, and drawing the boundary at the award so project management owns the job while the CRM holds the outcome.
Before any of it, count how many open pursuits point at the same physical project and whether the pipeline adds them together. In most contracting businesses it does, and that single behaviour explains more distrust of the forecast than every other issue on this list combined.