Insights · Business models
CRM for Contractors: Stages from Inquiry to Accepted Estimate
A CRM stage is useful when it helps someone understand what has happened and what to do next. Labels such as “new,” “follow-up” and “won” can conceal important differences if the team has not agreed on the evidence behind them.
For a contractor, the record should help connect a request, its suitability, the current estimate and the handoff into accepted work. This guide offers a sample stage design and a worksheet for adapting it to the way your business actually operates.
Separate the contact from the opportunity
A contact record describes a person or organization. An opportunity describes a particular request or potential piece of work. One contact can have more than one legitimate request over time.
Define how the team recognizes duplicates without collapsing separate jobs into one record. Preserve the original inquiry reference and connect later calls, emails or forms to the appropriate request.
This distinction supports reporting. Counting contacts, requests, estimates and accepted jobs as though they were the same unit makes the customer journey harder to evaluate.
Stage one: inquiry received
Use this stage when the request has arrived and a usable record exists. Preserve the original message, source and time, along with the service or project reference needed by the team.
The next action is to assign a responsible person or coverage role. An acknowledgment may tell the customer the request arrived, but it does not establish that the request is suitable or that someone has addressed the question.
Record missing information as a task or explicit field. A stage called “new” should not leave the team guessing whether a person has been assigned or whether a basic detail is still needed.
Stage two: suitability reviewed
Define the questions the business uses to determine whether it can consider the work. Those questions may concern service scope, coverage and the information required for the next step.
Record the outcome and its basis. A request that needs clarification is different from one outside the business's scope. A request that fits the service may still require an assessment before an estimate can be prepared.
Use an exit for unsuitable requests so they do not remain indefinitely in an active sales queue. Where appropriate, the response owner can explain the outcome using approved wording.
Stage three: assessment or estimate preparation
Some services require an assessment; others can be estimated from defined information. Represent the process your business uses and make any required appointment status explicit.
Keep a requested appointment separate from a confirmed appointment. Record who confirms the time and which calendar or operational record establishes it. The CRM should help the team locate that record rather than substitute an ambiguous label for it.
During estimate preparation, identify the responsible person and missing dependencies. The next stage should follow actual issuance of a proposal, not simply the intention to prepare one.
Stage four: estimate issued
Attach or link the current estimate with its reference and issue date. Preserve the described work, acceptance route and approved next step.
An estimate issued is not an estimate accepted. If the system records delivery information, label it accurately. A sent email, a viewed document and a customer reply each provide a different observation.
Assign the next action deliberately. It might be a planned follow-up, a clarification already requested by the customer or a review of information that affects the estimate. Explore estimate follow-up workflows for the communication around this stage.
Stage five: customer decision or scope review
When the customer replies, pause any sequence that could conflict with the conversation. Route the reply to the person responsible for answering it.
If the scope changes, preserve the relationship between versions. The team should be able to identify the proposal currently under discussion and which earlier version is no longer appropriate for follow-up.
Record a decline or closure as an outcome when it occurs. Do not move every silent inquiry into a positive stage simply because an automated sequence completed.
Stage six: accepted work and delivery handoff
Define the evidence that establishes acceptance in your actual process. Identify the accepted version and any remaining conditions before the record enters a delivery workflow.
The delivery owner needs more than a stage label. Provide the agreed scope, relevant customer context, current documents, unresolved dependencies and the person responsible for scheduling or further communication.
Keep operational events distinct. Accepted work, a confirmed schedule, completed delivery and collected payment should not be treated as interchangeable. Their separate records help the team understand what remains to be done.
Build a stage definition table
Use this template for each stage:
| Field | What the team needs to agree |
|---|---|
| Entry evidence | The event or record that supports moving into the stage |
| Required information | The details needed for a useful next action |
| Owner | The person or role responsible |
| Next action | The task or decision the stage should trigger |
| Exit evidence | What establishes progress, closure or escalation |
| Automation limits | What can happen automatically and what needs review |
Review the completed table with the people who use the records. A technically tidy pipeline is not useful if its labels do not match the team's work.
Test changes and exceptions
Walk sample records through the process. Include a duplicate inquiry, an unsuitable request, a changed estimate, a customer who replies during follow-up and an accepted job with a missing delivery dependency.
Check whether ownership remains clear and whether previous events can still be understood. A record moved backward for a scope review should not erase the fact that an estimate was issued earlier.
Keep a manual correction route and establish how the team will investigate an unexpected transition. Automations should make work more visible rather than hide uncertainty behind a sequence of stage changes.
Review the pipeline using real definitions
Report the number of inquiries, estimates issued and accepted work separately. State which records and period each measure includes, and keep unresolved or closed outcomes visible.
Use the review to improve the process. A repeated missing field may belong in intake. A repeated delay before estimate preparation may concern capacity or ownership. The stage map should help identify that decision.
Explore CRM for contractors to map one inquiry journey, its evidence and the handoff into delivery. Bring a sample process and the stage where the next action becomes unclear.