The default GHL pipeline setup looks clean in a demo. "New Lead," "Contacted," "Appointment Set," "Closed Won," "Closed Lost." Five stages, tidy progression, easy to understand. It's also almost completely useless for most real businesses.
I've never worked with a client whose sales process maps cleanly onto the default demo pipeline. Not once. And yet I see agencies deploy that default setup — sometimes with minor tweaks, sometimes unchanged — on client after client. Then six months later the client isn't using the pipeline, their team is logging things inconsistently, and the agency is getting blamed for a CRM that "doesn't work."
The pipeline didn't fail them. The setup did.
The Discovery Conversation You Have Before Building Anything
Before I touch a pipeline in GHL, I ask the client to walk me through their actual sales process out loud. Not what they think it should be — what actually happens. How does a lead come in? What's the first thing their team does? What are all the things that can happen between "new lead" and "closed"? What does a deal look like when it's stalled? When it's disqualified?
I also ask: what information does your team need to see at a glance when they're working a lead? Because that shapes what goes in custom fields versus what goes in stage names.
And the question most agencies skip: what's happened in the last five deals you lost? What stages did those go through? Where did they stall out? Closed-lost paths are where most pipeline designs fall apart — they get one bucket ("Closed Lost") when in reality there are three or four distinct reasons a deal dies, and those reasons warrant different follow-up paths.
That conversation almost always surfaces stages the default pipeline doesn't account for. "Quote Sent — Waiting on Response." "Demo Scheduled." "Contract Out." "Needs Follow-Up Next Quarter." These are real stages that happen in real sales processes. If your pipeline doesn't have them, your team will stop using the pipeline — because it doesn't reflect their reality.
I take notes during this conversation and draw out the stages on paper before touching GHL. That draft is what gets validated with the client before I build anything.
Common Pipeline Mistakes Beyond the Default
Even agencies who know not to use the demo pipeline often make versions of the same mistakes. Here's what I see repeatedly:
Too many stages. A pipeline with 14 stages sounds thorough. In practice, it means the sales team has to make a judgment call on stage placement every time a deal moves, and those judgment calls are inconsistent. Aim for 6–9 stages that represent genuinely distinct moments in the sales process.
Stage names that describe activity instead of outcome. "Emailed client" is an activity. "Proposal Delivered" is an outcome. Pipeline stages should reflect what's true about the deal at that point, not what action was just taken. This matters because automations trigger on stage — and activity-based names make it impossible to know what should actually fire.
No "Not Qualified" stage. Every pipeline needs a clean disqualification stage that's separate from Closed Lost. Closed Lost means the deal was real but didn't come through. Not Qualified means it should never have been in the pipeline. Conflating these two makes pipeline analytics meaningless.
Stages that exist for internal tracking instead of the sales process. I've seen "Needs Team Review" and "Assigned to Rep" as pipeline stages. These are workflow steps, not sales process steps. Track them with tags or custom fields, not pipeline stages.
Why Stage Names Matter More Than You Think
In GHL, pipeline stage names aren't just labels. They drive workflow triggers. If you're automating follow-up based on what stage a contact is in, vague stage names cause vague automations. "In Progress" tells you nothing and makes building reliable automations nearly impossible.
Good stage names are specific and action-oriented. "Discovery Call Booked" is better than "Contacted." "Proposal Sent" is better than "Negotiation." When a stage name describes exactly what happened, it's easy for the sales team to know where a deal belongs — and easy to build automations that fire at the right moment.
Automation Triggers Tied to Pipeline Stages — Specific Examples
A pipeline without automation is a glorified to-do list. Here's how I wire it up for real:
Stage: Discovery Call Booked
Trigger: Deal moves into this stage.
Automation: Send confirmation SMS and email with calendar details. Create a task for the assigned rep to review the contact record before the call. Add tag "discovery-scheduled."
Stage: Proposal Sent
Trigger: Deal moves into this stage.
Automation: Start a follow-up sequence — email or SMS at day 2, day 5, day 8. Sequence stops when the deal moves out of this stage (either forward or to Closed Lost). Add tag "proposal-out."
Stage: Closed Won
Trigger: Deal moves into this stage.
Automation: Trigger the onboarding workflow. Send a welcome email. Notify the internal ops team. Remove from any active follow-up sequences. Add "client" tag and remove "prospect" tag.
Stage: Closed Lost
Trigger: Deal moves into this stage.
Automation: Send a graceful breakup email (if appropriate for the client). Add to a re-engagement list. Schedule a follow-up task 90 days out to check back in. This one's often skipped, but a well-timed 90-day re-engagement brings deals back regularly.
Stage: Stalled / Needs Follow-Up
Trigger: Deal moves into this stage OR has been in any stage for X days without movement.
Automation: Task assigned to the rep's manager for review. Alert after 7 days of no movement.
The key with all of these: build the automation logic alongside the pipeline design, not as an afterthought. If you build the pipeline, go live with the client, and then try to add automations later, you'll find that your stage names were wrong or your stages were in the wrong order for the trigger logic you need.
Multi-Location and Multi-Service Clients
This is where most pipeline setups go sideways: clients who operate multiple locations, or who offer fundamentally different services under the same brand.
The rule I follow: one pipeline per distinct sales process. Not one pipeline per service. Not one pipeline per location. One per distinct process.
For a client with two locations in different markets, the sales process is usually the same — the stages, the touchpoints, the timeline are identical. In that case, one pipeline works fine, and you differentiate by tagging contacts with their location. You get consolidated reporting, which is actually what most multi-location clients want.
For a client who sells both a $500 one-time service and a $3,000 monthly retainer, those are two completely different sales processes. Different conversations. Different timelines. Different objections. Different follow-up cadences. Running both through the same pipeline means building stages that fit neither one well. You end up with a pipeline that everyone uses inconsistently because it doesn't quite match what they're actually doing.
I've built setups with four pipelines for a single client because they had four genuinely distinct offer types. It sounds like a lot until you see how cleanly the automations work when every pipeline maps to a real process.
For multi-location clients who do need location-level visibility, I typically use a combination of pipeline + custom field (location) + tags to create filtered views. GHL's pipeline reporting lets you filter by assigned user, and if you've assigned reps to specific locations, that gives location-level data without needing separate pipelines.
The Test Before You Go Live
Before any pipeline goes live for a client, I create a test contact and manually move it through every stage. I watch what automations fire. I check that notifications go to the right people. I confirm that stage-based triggers work the way they're supposed to. Then I do it again with a contact that takes an unusual path — someone who skips a stage, or re-enters the pipeline after being closed.
This sounds like extra work. It takes maybe 30 minutes. The alternative is discovering edge cases after the client is actively using the pipeline, which is much harder to fix without disrupting live deals.
After testing, I also do a quick run-through with whoever on the client's team will be managing the pipeline day-to-day. Not a training session — a 15-minute walkthrough where they move a test deal through the stages while I watch. If they hesitate on any stage or ask where something belongs, that's a signal the pipeline design needs adjustment before it goes live.
A pipeline that makes sense to you as the builder but confuses the person using it every day is a pipeline that won't get used.