CRM Examples: Real Pipeline Setups for Small Service Businesses
Most CRM examples show a generic pipeline: Lead, Contacted, Proposal, Won, Lost.
It's not wrong. It's also not what anyone actually ends up with, and it doesn't tell you the thing that matters — which decisions determine whether the pipeline stays current or rots within a quarter.
Four real setups below. Each shows the stages, the fields, the rules, and what had to be fixed after the first attempt.
Anonymised, but the structures are real.
The rule underneath all four
A stage is a state the record is in, not a task someone performs.
| Task (breaks) | State (works) |
|---|---|
| Send proposal | Proposal sent |
| Follow up | Awaiting response |
| Chase for decision | Negotiating |
A state can be verified by looking. A task can't — a half-done task leaves the record nowhere, so it stops moving, and a pipeline where records stop moving is already dead.
Every one of the four examples below got this wrong on the first attempt.
Example 1 · Auto service and tyre fitting
High volume, short cycle, mostly phone enquiries. The challenge is speed, not complexity.
Pipeline:
| Stage | Entry | Exit | Max age |
|---|---|---|---|
| New | Enquiry recorded | Someone has spoken to them | 2 hours |
| Quoted | Price given | They respond | 3 days |
| Booked | Appointment in the diary | Work day arrives | — |
| Completed | Work done, paid | — | — |
| Lost | Declined or no response | — | — |
Required fields:
| Field | Type | Required at |
|---|---|---|
| Source | Dropdown: Google, Facebook, referral, passing trade, returning | Creation |
| Vehicle | Text | Creation |
| Service type | Dropdown | Quoted |
| Quoted value | Number | Quoted |
| Lost reason | Dropdown | Lost |
What was wrong first: the original pipeline had seven stages including "Call back" and "Waiting for part." Both were tasks. Records accumulated in "Call back" because nobody could tell whether a call that went to voicemail counted.
The fix: "Call back" became a next-action date rather than a stage. "Waiting for part" became a field on the Booked stage.
The rule that mattered most: a two-hour maximum on New. For this business, speed of first response was the single largest determinant of whether a job converted. Making that a visible, measured threshold changed behaviour more than any other change.
Example 2 · Personalised product e-commerce with a custom-order line
Two processes in one business: standard online orders, which don't need a pipeline at all, and custom orders, which do.
Pipeline — custom orders only:
| Stage | Entry | Exit | Max age |
|---|---|---|---|
| Enquiry | Custom request received | Requirements understood | 1 day |
| Specifying | Details being agreed | Quote sent | 5 days |
| Quoted | Price with the customer | They respond | 7 days |
| Approved | Paid or deposit taken | Production starts | 2 days |
| In production | Being made | Shipped | per product |
| Delivered | Shipped and confirmed | — | — |
| Lost | Declined or gone quiet | — | — |
Required fields:
| Field | Required at |
|---|---|
| Source | Creation |
| Product category | Enquiry |
| Personalisation details | Specifying |
| Quoted value | Quoted |
| Deposit taken | Approved |
| Promised date | Approved |
| Lost reason | Lost |
What was wrong first: standard orders were being put in the same pipeline. Hundreds of records moving automatically through stages, burying the twenty custom orders that actually needed attention.
The fix: standard orders stayed in the store platform and out of the CRM entirely. The pipeline covers only work that requires a human decision.
The rule that mattered most: "Personalisation details" required before leaving Specifying. Previously these lived in email threads, and production errors traced back to someone working from a half-remembered conversation.
Example 3 · Fashion and bridal with an atelier
Long cycle, high value, multiple appointments per customer. The pipeline has to survive months.
Pipeline:
| Stage | Entry | Exit | Max age |
|---|---|---|---|
| Enquiry | First contact | Appointment booked | 2 days |
| Appointment booked | Date in the diary | They attend | — |
| Attended | Visit happened | Decision or follow-up | 7 days |
| Considering | Thinking about it | Decision | 21 days |
| Ordered | Deposit paid | Fittings begin | — |
| In production | Being made or altered | Final fitting | — |
| Completed | Collected | — | — |
| Lost | Declined or gone quiet | — | — |
Required fields:
| Field | Required at |
|---|---|
| Source | Creation |
| Event date | Enquiry |
| Appointment date | Appointment booked |
| Attended? | After the appointment date |
| Estimated value | Attended |
| Deposit | Ordered |
| Lost reason | Lost |
What was wrong first: no stage distinguished between someone who had booked an appointment and someone who had attended one. Both sat in the same place, so the no-show rate was invisible — and it turned out to be significant.
The fix: separating Booked from Attended, with the Attended field required once the date passes.
The rule that mattered most: capturing the event date at enquiry. It determines urgency, it determines whether the work is even possible in the time available, and it drives every follow-up decision. Previously it was collected at the appointment, which was too late to prioritise.
The honest caveat: a 21-day maximum on Considering is long, and for this business it's correct. A purchase of this kind takes time. Copying a short cycle's thresholds onto a long one produces a pipeline that marks live opportunities as lost.
Example 4 · Systems and automation consulting
Low volume, high value, long consideration. The opposite shape from Example 1.
Pipeline:
| Stage | Entry | Exit | Max age |
|---|---|---|---|
| New | Enquiry recorded | Qualification call held | 5 days |
| Qualifying | Being assessed for fit | Decision to propose or decline | 5 days |
| Proposed | Offer with them | They respond | 10 days |
| Negotiating | Terms in discussion | Agreement or decline | 21 days |
| Won | Agreed | — | — |
| Lost | Declined or gone quiet | — | — |
Required fields:
| Field | Required at |
|---|---|
| Source | Creation |
| Business type | Qualifying |
| Process in scope | Qualifying |
| Fit score | Qualifying |
| Estimated value | Proposed |
| Next action + date | All open stages |
| Lost reason | Lost |
What was wrong first: no qualification stage at all. Enquiries went straight to a proposal, which meant time spent writing proposals for businesses that were never going to be a fit.
The fix: a qualification stage with a scored fit assessment, and a willingness to decline. The decline rate went up, and so did the proportion of proposals that converted.
The rule that mattered most: next action and date required on every open record. With low volume and long cycles, the failure mode isn't chaos — it's silence. A record sitting untouched for six weeks looks exactly like one that's progressing.
What the four have in common
Five to seven stages. Every one of them started with more and cut back. Beyond seven, the distinctions stop being meaningful and records stop moving.
Every stage has a maximum age. Different per business — two hours in one, twenty-one days in another. Having a number is what matters.
Lost reason is always required. It's the single most valuable field in a CRM and the one most often missing. Six months of lost reasons tells you more about your sales process than any analysis of what you won.
Dropdowns, not free text. A free-text source field produces "Facebook," "FB," "facebook ads" and "social" as four separate sources, and no report can fix that afterwards.
The first attempt had task-stages. All four. It's the most common CRM design error and it's the one that kills the pipeline fastest.
What none of them did
No elaborate field sets. Between five and seven required fields each. A CRM with forty fields has thirty that are blank, and the blanks make the populated ones look unreliable too.
No automatic stage movement. Records are moved by people. Automating the movement produces a pipeline that advances on its own and reflects nothing.
No separate pipeline per service. One pipeline, a field for the distinction, filter when needed. Six pipelines means no overall view and records in the wrong one.
Building your own
Start with three decisions, before touching any software:
What are the states a piece of work can be in? Not the tasks. The states. Five to seven.
How long can something sit in each one before it's stale? Pick numbers.
What does "lost" mean? How long without a response. This is the decision everyone avoids, and avoiding it is why pipelines inflate until the forecast is fiction.
Everything else — fields, tags, automation — follows from those three.
A stage is where something is, not what someone needs to do. Get that right and the rest is configuration.
Want a pipeline designed around how your business actually works?
A free systems audit covers your current setup, your data quality, and what to fix first.