HubSpot Pipeline Design Case Study: One Deal Pipeline Across Sales, Rigging and Delivery at a Boat Dealer

Summary

Blue Channel Marine sells, rigs, delivers and services boats. A single customer relationship runs from an enquiry at a boat show, through a quote and a deposit, into a rigging bay where parts are ordered and a build is completed, out through a scheduled delivery with a signed handover, and on into years of warranty and service work.

The design question is where to put the boundary. A conventional answer gives sales a deal pipeline that ends at closed won, and gives operations something else entirely. That answer was rejected, and the pipeline built instead runs ten stages from first contact to delivery sign-off, with a separate seven-stage ticket pipeline carrying service and warranty afterwards.

That decision has a consequence the platform does not warn about. HubSpot attaches a win probability to every deal stage, and the field assumes every stage is a selling stage. Once stages six through nine are a physical build, the probability on those stages is not a probability of winning. It is a likelihood of finishing. Both are legitimate numbers and they do not belong in one forecast without being separated.

Client details are pseudonymised at the client's request. Figures are as measured.

Background: the handoff is where the leaks are

The commercial problem was described consistently by everyone in the business, which is unusual and useful.

Leads arrived from advertising, the website, walk-ins, boat shows and referral, and were worked by representatives who decided individually what to send and when. Handoffs between sales, rigging, delivery, service and finance were verbal. Leadership had no single view of pipeline health, rigging capacity or service backlog. Nothing followed a customer after delivery, so referral and repeat purchase depended on the customer remembering the dealer rather than the reverse.

Every one of those is a boundary problem. A lead does not leak in the middle of a stage; it leaks at a handoff where one person's responsibility ends and nobody's has started.

Moncrief and Marshall (2005) revisit the linear model of selling and find its stages increasingly overlapping with functions outside sales, which is the condition here in a physical form: a deal at the rigging stage is a boat on a bay, and the person who can advance it is a technician.

Pre-engagement audit

Lead sources feeding the same undifferentiated pool: five. Advertising, website, walk-in, boat show and referral, none carrying a detail field that distinguished them at a level the marketing spend could be judged against.

Automated handoffs between departments: zero. Sales to operations, operations to delivery, delivery to service, and everything to finance, all ran on conversation.

Email templates in the legacy system: 11, used inconsistently, with no timing attached to any of them.

Follow-up after delivery: none automated. The highest-propensity moment for a referral in the entire relationship had no process behind it.

Dashboards covering pipeline, capacity or backlog: zero.

Speier and Venkatesh (2002) document that sales force automation fails most often where it asks salespeople to carry process that ought to be automated. A representative deciding individually what to send and when is not a discipline problem; it is a system that has delegated a scheduling decision to a person who is busy.

The build

Phase one: a pipeline that crosses two departmental boundaries

Ten stages, plus a terminal lost stage: New Lead, Sales Follow-Up, Qualified, Quote or Proposal, Negotiation, Deposit and Job Creation, Rigging and Build, Pre-Delivery, Delivery, Closed Won.

Ownership changes twice. Stages one to five are sales-owned. Stage six is the handoff, where a deposit converts a commercial agreement into a work order. Stages seven to nine are operations-owned, with sales supporting customer communication. Stage nine is shared: sales runs the customer orientation and operations confirms the boat is ready.

Eight of the ten stages carry required properties that gate the exit. A deal cannot leave the quote stage without make, model, year, stock number, motor details, list price, selling price and quote status. It cannot leave deposit without a deposit amount and date. It cannot leave pre-delivery without a completed rigging checklist, an actual completion date, a financing status where applicable, and a scheduled delivery date.

Gating on properties rather than on judgement is what makes the pipeline a control rather than a description. A stage a deal can leave without evidence is a stage that records an opinion.

Wang and Strong (1996) define data quality by fitness for the consumer's use, and the consumer of a stage transition is whoever reads the pipeline afterwards. A delivery date entered before the boat was ready satisfies every intrinsic test of correctness and fails that one, which is why eight of the gates test for the presence of evidence rather than for the plausibility of a value.

Phase two: the field that changes meaning halfway down

Every HubSpot deal stage carries a win probability, and the values here run from 5% at new lead to 100% at closed won.

Through stage five, those numbers mean what the platform intends: the likelihood that a commercial negotiation converts. From stage six they mean something else. A deal at rigging is a boat with a paid deposit and a work order. The commercial outcome is settled. The 85% attached to that stage is not a chance of winning the sale, it is a chance the job completes on the expected terms and timeline.

Lawrence, Goodwin, O'Connor and Önkal (2006) review judgmental forecasting and find that combining forecasts of different kinds without distinguishing them degrades the result. A weighted pipeline total summed across all ten stages is exactly that combination: it adds a sales forecast to a delivery schedule and reports one number.

The resolution is not to abandon probability. It is to report the two segments separately, so that a leadership dashboard shows a weighted sales forecast across stages one to five and a committed backlog across stages six to nine, and never adds them into a single figure labelled pipeline.

Phase three: eight property groups, named by prefix

Properties are prefixed by domain: qualification, boat, quote, deposit, rigging, delivery, financing and service.

A naming convention is a small thing that pays continuously. A technician looking for the parts status finds every rigging field adjacent in a filtered list rather than scattered through an alphabetical one, and a report builder selecting delivery fields cannot pick up a service field by mistake because the two never sort together.

Redman (1998) treats poor data quality as a cost borne continuously and recognised rarely, and property sprawl is one of its quietest forms. A portal with two hundred ungrouped custom properties is a portal where the wrong field gets populated, and no single event ever makes that visible.

Phase four: the service pipeline and the stage that can be skipped

Service and warranty run on a separate seven-stage ticket pipeline: New Request, Triage and Estimate, Waiting on Parts, Scheduled, In Progress, Quality Check and Ready for Pickup, Closed.

One of those stages is optional. A job needing no parts should not pass through Waiting on Parts, and a pipeline that forces it to either teaches the team to lie to the system or produces a backlog report containing jobs that are not waiting for anything.

The resolution is a workflow that advances the ticket automatically when the parts-needed property is empty, so the stage exists for the jobs that need it and is invisible to the jobs that do not. That is a small piece of automation covering a structural mismatch between a linear stage model and work that branches.

A warranty ticket is created automatically at closed won, which is the mechanism that converts a completed sale into a service relationship without anyone remembering to do it.

Phase five: eleven templates, seven workflows, five dashboards

The eleven legacy templates were migrated, brought to a consistent brand, and placed inside timed sequences, which moves the decision about what to send and when from a representative's memory into the system.

Seven workflows cover lead response time, quote follow-up, deposit chasing, rigging status updates, delivery scheduling, post-sale review requests and service reminders. Text messaging sits alongside email at the moments where response rates justify it: appointment confirmation, delivery scheduling and service reminders.

Five dashboards divide by audience rather than by data source: an executive view of forecast, pipeline value, close rate, capacity and cash timing; a sales view of lead volume by source and conversion by stage; an operations view of jobs in progress, parts status and days to complete; a service view of open tickets and warranty claims; and a finance view of deposit timing, margin and discount frequency.

Dividing by audience rather than by data source is a deliberate inversion of the usual approach, and Speier and Venkatesh (2002) supply the reason: adoption fails where a system presents a person with information belonging to somebody else's job. A technician who has to filter past a cash-timing chart to find a parts backlog will stop opening the dashboard, and the parts backlog will go back to being a conversation.

Outcomes

Deal pipeline stages: from an undocumented process to 10, plus a terminal lost stage.

Stages with required properties gating exit: 8 of 10.

Departments the single pipeline spans: 3, with ownership changing at stage six and shared again at stage nine.

Service pipeline stages: 7, one of which is skippable by workflow rather than by instruction.

Email templates migrated from the legacy system: 11, each placed inside a timed sequence.

Automation workflows: from 0 to 7, covering response time, quote follow-up, deposit chasing, rigging status, delivery scheduling, post-sale review and service reminders.

Dashboards: from 0 to 5, divided by audience.

Property groups: 8, prefixed by domain.

Automated post-delivery follow-up: from none to a sequence triggered by the closed won transition, alongside automatic warranty ticket creation.

Lessons learned

The handoff is worth more design attention than the stages either side of it. Stage six exists because a deposit is the moment a commercial agreement becomes a physical commitment, and both departments need to see the same record at that instant. Splitting the pipeline there, which is the conventional choice, would have put the most failure-prone moment in the relationship on a boundary between two systems.

A platform field can be correct and still be misread. Win probability is doing its job at every stage. The mistake available here is summing across stages that mean different things, and the platform will happily produce that sum. No configuration prevents it; only a reporting decision does.

An optional stage needs automation, not a rule. Telling representatives to skip a stage when it does not apply produces inconsistent data within a week. A workflow that advances the ticket when the parts field is empty produces the same outcome and needs nobody to remember it.

Migrating templates was less valuable than scheduling them. Eleven templates already existed and were already reasonable. What did not exist was any answer to when each one goes out, and a sequence supplies that answer once for everyone rather than repeatedly for each representative.

Limits

This describes a specification and a build sheet, not a measured result. The stage model, properties, workflows, sequences and dashboards are as designed and built. The document that governs the work also contains a quality assurance and user acceptance checklist covering stage transitions, workflow verification, reporting accuracy and sequence enrolment. Results of that testing are not reported here, and no business outcome is claimed.

Nothing here establishes that leads stopped leaking. The design closes specific handoffs with specific automation. Whether the leak rate fell is a measurement the engagement has not yet produced, and the baseline leak rate was never quantified, which would make an improvement claim unfalsifiable even if one were made.

Text messaging depends on consent the design does not create. The channel is layered in where response rates justify it, and every recipient still has to have agreed to receive it.

A deal pipeline carrying physical state has a reporting hazard beyond the probability one. A boat delayed on a parts backorder sits at the same stage as a boat progressing normally, so any report on time-in-stage across stages seven to nine mixes a supply problem with a scheduling one unless it is filtered by the parts status property.

Capacity is visible and not modelled. The operations dashboard shows jobs in progress and days to complete. Nothing in the design constrains how many jobs may enter rigging at once, so the pipeline can show a commitment the workshop cannot meet.

This is a dealer that rigs what it sells. A dealer selling boats that ship complete has no stages seven and eight, and the entire probability argument disappears with them.

Conclusion

The choice worth carrying out of this engagement is where a pipeline is allowed to end.

Ending it at closed won is tidy, and it puts the most fragile part of the customer relationship, the weeks between a paid deposit and a delivered boat, outside the system that everyone reports from. Running it through delivery keeps that period visible and costs one thing: a field that means two things, which has to be reported as two things.

Reinartz, Krafft and Hoyer (2004) find the maintenance stage of customer relationship management most strongly associated with performance and most weakly implemented. At a boat dealer, maintenance begins the day the deposit is paid and continues for as long as the customer owns the boat. A pipeline that stops at the sale has measured the part of that relationship the customer thinks least about.

References

Lawrence, M., Goodwin, P., O'Connor, M., & Önkal, D. (2006). Judgmental forecasting: A review of progress over the last 25 years. International Journal of Forecasting, 22(3), 493–518. https://doi.org/10.1016/j.ijforecast.2006.03.007

Moncrief, W. C., & Marshall, G. W. (2005). The evolution of the seven steps of selling. Industrial Marketing Management, 34(1), 13–22. https://doi.org/10.1016/j.indmarman.2004.06.001

Redman, T. C. (1998). The impact of poor data quality on the typical enterprise. Communications of the ACM, 41(2), 79–82. https://doi.org/10.1145/269012.269025

Reinartz, W., Krafft, M., & Hoyer, W. D. (2004). The customer relationship management process: Its measurement and impact on performance. Journal of Marketing Research, 41(3), 293–305. https://doi.org/10.1509/jmkr.41.3.293.35991

Speier, C., & Venkatesh, V. (2002). The hidden minefields in the adoption of sales force automation technologies. Journal of Marketing, 66(3), 98–111. https://doi.org/10.1509/jmkg.66.3.98.18510

Wang, R. Y., & Strong, D. M. (1996). Beyond accuracy: What data quality means to data consumers. Journal of Management Information Systems, 12(4), 5–33. https://doi.org/10.1080/07421222.1996.11518099

Conflict of Interest Statement

RevOps HQ is a HubSpot Solutions Partner and was paid to design and build the configuration described here. Stage names, probabilities, property groups, workflow counts and dashboard definitions come from the approved build sheet. The document is a specification of work, and where results of that work are not yet measured, this study says so rather than implying otherwise.

Acknowledgments

The stage model reflects the dealer's own sequence from enquiry through rigging to delivery, documented with the sales, operations and service leads rather than adapted from a reference pipeline.