A Minimum Viable CRM Pipeline for a Small Contractor

Build the pipeline around decisions

A small contractor needs to know which enquiries need a reply, which visits need preparation and which quotes need a decision. A CRM pipeline should make those questions easy to answer. Start with a record for each distinct project and stages that describe observable progress. A contact may have several projects; several messages may relate to the same project.

The structure below is an editorial starting point, usable in a CRM or spreadsheet. HubSpot describes pipelines as stages showing where a record sits in a process and supports conditional properties at stage changes. Those capabilities can enforce your rules, but the business must define the rules first.

Use a small set of stages with entry evidence

Name stages for a state the team can verify. Calling a record 'hot' says little about what happened; 'quote sent' can be checked against a dated document. Begin with the stages below and remove any that your actual process does not use. A remotely quoted project can bypass the visit stages with a recorded explanation.

Keep waiting reasons in a separate field. 'Waiting for photos' and 'waiting for material selection' often require different actions but do not need separate pipeline columns.

Define what an open record must contain

Require enough information to manage the enquiry. At creation, that means a project identifier, contact, service location or area, requested work, received date, source and owner. As the project progresses, add the visit details, quote reference, quoted amount when known, last meaningful contact, next action and due date. Leave unknown amounts empty rather than inventing a value to fill the board.

Keep the person, property and project distinguishable, even if they occupy one spreadsheet row. Search existing records before adding another. Two household members discussing the same scope should usually connect to one project record. A later, separate project should retain its own history.

Project ID: [unique reference]
Contact and reply details: [name/channel]
Property/service area: [location]
Requested scope: [short factual summary]
Source and received date: [source/date]
Owner and stage: [person/state]
Last meaningful contact: [date/outcome]
Next action: [verb + specific result]
Action due: [date/time]
Waiting reason: [if applicable]
Visit/quote references: [links]
Outcome and reason: [when closed]

Make the next action more useful than a note

'Follow up' leaves the next person to work out why. 'Call to confirm whether the revised finish specification is acceptable' identifies an action and its purpose. Assign it to one person and give it a due date based on the customer's agreement or the team's operating routine.

A record can remain in 'quote sent' while several tasks occur. Completing a task does not automatically mean the customer has progressed to a new stage. HubSpot's task documentation provides a concrete implementation: tasks can have a record association, assignee, due date and notes.

• After each meaningful conversation, save the outcome and replace the completed action.
• If waiting for the customer, record exactly what is needed and when the owner will review it.
• If the customer requests contact later, use the agreed date rather than repeated unscheduled reminders.
• If the enquiry ends, close it with a reason instead of leaving an expired task open.

Decide what won and closed actually mean

Write one internal sentence defining the evidence needed for 'won', then use it consistently. The definition should match how the business accepts work. Record the accepted scope and quote version, the acceptance evidence and any operational prerequisites still outstanding. A friendly conversation or a request for availability does not by itself satisfy that definition.

Use factual closure reasons: outside service area, unsupported work, timing mismatch, customer postponed, customer declined or no response after the team's defined contact process. Record a price objection only when the customer states it. 'Unknown' is more useful than a guessed reason. HubSpot includes a closed-lost reason property, illustrating how outcome detail can be stored separately from the stage.

Keep a deferred project with an agreed future review date distinct from a lost opportunity. If the team archives it administratively, retain that closure rule and the actual customer response; do not label the project a competitive loss.

Review exceptions before reading the whole board

Start each working day with unassigned enquiries, overdue actions, upcoming visits with missing details and quotes whose promised send date has passed. Resolve each exception by doing the action, assigning it, revising the commitment with context or closing the record. Moving a due date without recording a reason conceals the problem.

At a regular team review, inspect records that have stayed in one stage longer than your normal workflow would suggest. Look for missing scope, unavailable capacity or an unrecorded customer decision. Stage age prompts investigation; it is not proof that the customer is lost. Keep sales progress separate from installation scheduling, purchasing and invoicing so the board continues to answer the sales questions it was built for.

Add reporting only after the records are reliable

Begin with counts of new enquiries, visits completed, quotes sent, won projects and closed outcomes. Compare records created in a defined period if measuring enquiry-to-order conversion, and show how many remain open. Dividing this month's wins by this month's enquiries mixes projects at different points in their decision cycle.

Before adding automation, test the workflow on current enquiries: can another person identify the stage evidence and next action from the record? Fix unclear fields and unused stages first. Then automate predictable reminders or required fields. The minimum viable pipeline is the smallest structure the team consistently keeps accurate.