HubSpot Service Hub Implementation Case Study: Post-Signature Client Ownership at a Family Law Firm

Summary

Prescott Family Law is a multi-office family law practice running HubSpot as its client system of record, with a sales pipeline owned by intake closers and separate ticket pipelines for customer care, billing, collections and information technology. Clients were leaving after signature rather than before it, and the firm's own complaint records pointed at a single cause: once the deal closed, no named person owned the relationship.

The technical statement of that problem is narrower and more useful. When a deal reached the Case Accepted stage, HubSpot created a task. A task carries an owner and a due date. It does not carry a stage, a service-level agreement, an exit criterion or a queue, so the portal could not answer how many retained clients had been contacted, how long any of them had waited, or which were at risk. The relationship existed as an event in several pipelines and as an object in none.

This case study describes the build that gave it an object: a Client Experience pipeline of eight stages with hard gates, 21 new properties across two object types, 13 workflows, a ten-report dashboard, seven templates and six lists. It also records what the build could not settle, including a risk-tier automation that shipped with a human in the loop and a drop-off baseline that was never captured before launch.

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

Background: a relationship with no record

Family law is a referral and reputation business with an unusually long tail of dissatisfaction. A matter runs for months, the client is under strain throughout, and the moment of greatest risk is not the pitch. It is the silence after signature.

The firm had built its commercial operation around the close. Intake closers worked a HubSpot deal pipeline and were measured on retention agreements signed. Everything downstream ran on ticket pipelines owned by functional teams: customer care handled complaints, billing handled invoices, collections handled arrears. Each pipeline was competently configured. None of them described the client.

Bitner, Booms and Tetreault (1990) classify service encounters by the incidents that make customers remember them, and find that a large share of unfavourable incidents arise not from the core service but from the handling of a request, a delay or a failure. A firm with four functional pipelines and no relationship pipeline has instrumented the core service and left the handling uninstrumented.

The gap had a precise technical shape. A deal entering Case Accepted fired a workflow that created a task. Tasks in HubSpot have no pipeline, no stage, no service-level agreement and no reporting surface beyond completion. A supervisor could see that tasks existed. Nobody could see that a retained client had gone nineteen days without contact, because no property recorded the last contact and no view grouped clients by how long they had waited.

Pre-engagement audit

The audit ran over two working sessions in March 2026 and covered the deal pipeline, the four existing ticket pipelines, the property schema on Contact, Deal and Ticket, and the reporting surface available to firm leadership.

Objects describing a retained client: one, and it was the wrong one. A retained client was represented by a closed-won deal. A closed-won deal is a terminal record of a sale. It has no state after closure, so it cannot represent an engagement that continues for months.

Properties recording post-signature state: zero. Contact carried no owner for the post-signature relationship, no risk level, no communication preference and no record of last contact. Each of those was held informally, in the memory of whoever had last spoken to the client.

Reports on post-signature health: zero. Firm leadership could report on deals closed and tickets resolved. No report answered how many retained clients were active, how many were at risk, or how long a client waited between contacts.

Meeting records requiring remediation: 1,152. A separate data-quality problem, already in progress under the firm's operations lead, affected meeting status values across historical records. It did not block the build, and it did constrain what the resulting dashboard could report on historical periods.

Integration constraints: two, one of which was structural. The native integration between the firm's scheduling tool and HubSpot could not pass dynamic form variables into HubSpot meeting records, so case type was absent from the meeting object at the point of handoff. The firm's practice management system held case status behind a confidentiality review that had not concluded.

Redman (1998) frames poor data quality as an operating cost rather than a hygiene irritation, and the framing holds here: absent fields were not untidiness, they were the reason a question could not be asked.

The build

Phase one: the pipeline and its gates

The Client Experience pipeline was built with eight stages: New Client, Welcome Call Scheduled, Active Engagement, At Risk, Escalated, Closing, Post-Case Follow-up and Closed.

Two design decisions carry the pipeline. The first is that the welcome call is a hard gate. No ticket may reach Active Engagement until the welcome-call checkbox is set, which means a client cannot be counted as under management before a human has spoken to them. The second is that At Risk is not a terminal state and not a detour. It exits in two directions, back to Active Engagement when the risk resolves, or forward to Escalated when it does not, and Escalated returns to Active Engagement once a resolution is recorded.

Post-Case Follow-up carries a 365-day time to live. A matter that closes does not end the relationship; the pipeline holds the client for a further year on a monthly cadence, then closes automatically.

Phase two: the property schema and the sync boundary

Twenty-one new properties were created, seventeen on Ticket and four on Contact, alongside one change to the Deal object: an enrollment trigger added to a single existing stage.

Four properties exist on both Ticket and Contact by intent rather than by accident. Risk level, communication preference, best contact time and coordinator assignment are held in both places because they answer different questions. The ticket holds point-in-time state for one engagement. The contact holds the latest known value across every engagement the person ever has with the firm.

That duplication requires a stated sync direction, and an unstated one is how dual-write schemas corrupt themselves. Contact values flow to the ticket once, at creation. Ticket values flow back to the contact on update. The contact is therefore the durable record and the ticket is the working one, and a returning client arrives with their preferences already known.

Wang and Strong (1996) argue that data quality is defined by fitness for the consumer's use rather than by intrinsic accuracy, which is the argument for holding the same value twice. The coordinator preparing a welcome call and the supervisor reporting on portfolio risk are different consumers with different needs, and one field cannot serve both without losing history.

Phase three: the thirteen workflows

The workflows divide into four groups.

Creation and assignment, two workflows. A deal entering Case Accepted creates the ticket, copies nine properties from the deal and contact, sets the coordinator on both objects, and notifies the coordinator and the assigned legal team. A second workflow maps the coordinator dropdown value onto the native HubSpot ticket owner, mirroring the pattern already used by customer care, billing and collections.

Service-level enforcement, two workflows. The welcome-call workflow waits 24 hours, checks the completion flag, notifies the coordinator and the supervisor if it is unset, waits a further 24 hours and escalates to the firm's owner at 48. The missed-check-in workflow fires when the next-due date passes without the last-contact date having moved, notifies, waits 48 hours and escalates.

Cadence and state, five workflows. Cadence derives from risk: high and medium risk produce a weekly cadence, low risk biweekly, post-case monthly. A risk change to high resets the cadence, recalculates the next due date, notifies both the coordinator and the supervisor, and syncs the elevated level to the contact. Case closure moves the ticket to Closing and creates the exit-interview task. Exit-interview completion moves the ticket to Post-Case Follow-up and starts the 365-day clock. The clock's expiry closes the ticket and clears the coordinator assignment from the contact.

Routing and notification, four workflows. Escalation branches on a required reason field, with five values routing to four different destinations, and the workflow holds rather than firing if the reason is empty. A weekly digest sends active counts, overdue check-ins, at-risk counts and compliance rates to the whole team on Monday mornings.

Phase four: the reporting surface

Ten reports on one dashboard, of which four are the ones the firm did not previously have in any form: welcome-call compliance as a percentage against a 95% threshold, check-in compliance measured as last-contact date against next-due date, risk distribution as a live count by tier, and workload as a table of coordinator against stage.

Payne and Frow (2005) place performance assessment among the cross-functional processes that distinguish customer relationship management from contact storage, and the distinction is exactly the one at issue: the firm had stored contacts for years and had never assessed the process.

Outcomes

The firm's own success criteria are targets with a six-month and twelve-month horizon, and the engagement is not yet at either. What follows is therefore reported as capability delivered, not as business outcome achieved. The limits section states that distinction again, because it matters.

Owner of the post-signature relationship: from zero to one named person per retained client. The coordinator assignment is set by workflow at ticket creation and written to both the ticket and the contact. Before the build, the question had no answer in the system.

Pipeline stages describing a retained client: from 0 to 8. A retained client now occupies a stage, and the stage has an exit criterion.

Custom properties recording post-signature state: from 0 to 21. Seventeen on Ticket and four on Contact, of which four are the same value held on both objects. One further change was made to an existing Deal stage.

Automated workflows governing the relationship: from 1 to 13. The one that existed created a task.

Reports on post-signature health: from 0 to 10. Four of them are compliance measures that had no data source before the properties existed.

Service-level agreement on first contact: from none to 24 hours, escalating at 48. The agreement is enforced by workflow rather than by instruction, which is the difference between a policy and a control.

Post-case engagement window: from 0 to 365 days. Monthly contact, terminated automatically by the day count.

Operational assets delivered: 60. One pipeline, 21 properties and one deal-stage change, 13 workflows, one dashboard carrying ten reports, seven email templates, six lists, and one onboarding procedure of ten steps with a seven-step reversal.

Lessons learned

A ticket pipeline is a data model before it is a workflow. The temptation on a build of this shape is to start with the automation, because automation is what the client asks for. The automations were the last thing built and the least contested. Every argument that mattered was about whether a value belonged on the ticket or the contact, and each of those arguments was settled by asking which question the value would be used to answer.

The risk automation shipped with a human in the loop, and that was the right call. The original design derived risk tier automatically from withdrawal indicators. The indicators were never defined, because defining them required an analysis of historical withdrawals that the firm had not performed. Rather than encode a guess, the tier was launched as a manual field set by the intake closer and revisable by the coordinator, with the cadence automation firing off whatever value a human had entered. The automation around the field is complete. The field's input is judgement, and will remain so until the underlying analysis exists.

The scheduling integration had to be routed around rather than through. The native connector between the firm's scheduling tool and HubSpot maps a fixed set of fields and cannot pass dynamic form variables into meeting records. Case type was therefore absent from the meeting object at exactly the point where the handoff needed it. The resolution was a webhook path into the HubSpot meetings API rather than a change to the connector, and the pipeline was designed to degrade rather than fail when the field is empty: a ticket created without case type is created anyway, with a blank field and a notification that says so.

Customer experience management is a capability assembled from cultural mindsets, strategic directions and firm capabilities together (Homburg, Jozić, & Kuehnl 2015), and the sequencing lesson here is consistent with that: the pipeline is the firm capability, and it was built to support a role the firm had decided to create, not to substitute for one.

Limits

No business outcome is reported here, and none should be inferred. The firm's stated targets are a 25% reduction in drop-off at six months and 40% at twelve. Neither has been measured, and one reason is recorded in the engagement's own open-items list: the pre-launch drop-off baseline was never captured. A percentage reduction against an unknown baseline is not a measurement.

The capability figures are build counts, not performance counts. Thirteen workflows exist and fire. Whether coordinators meet the 24-hour service-level agreement is a question the dashboard can now answer and this document cannot, because the engagement has not run long enough to produce a meaningful series.

The historical reporting surface is constrained by data the build did not fix. The 1,152 meeting records under remediation limit what any trend report can say about periods before the cleanup concludes.

One integration remains unresolved. Case status from the practice management system is not available to coordinators, pending a confidentiality review with no completion date. Coordinators obtain status verbally. The build does not depend on the integration, and the absence is a real constraint on the role.

The design assumes one coordinator per client and one active ticket per matter. A firm with shared ownership or with multiple concurrent matters per client would need a different association model, and the deduplication check in the creation workflow would need to become a genuine idempotency key rather than a simple existence test.

Conclusion

The failure this build addresses was not a failure of effort or of intention. Four functional teams handled retained clients attentively and none of them owned the relationship, because the system offered no object to own it with.

Reinartz, Krafft and Hoyer (2004) measure customer relationship management as a set of processes implemented at the relationship stages of initiation, maintenance and termination, and find maintenance the stage where implementation is weakest and the performance association strongest. A firm with a rigorous initiation process, no maintenance process, and a termination process consisting of a closed-won deal going quiet is the ordinary case rather than the exceptional one.

What changed is narrow and checkable. A retained client now has an owner, a stage, an exit criterion, a contact cadence derived from a risk level, an escalation path with a required reason, and a clock that runs for a year after the matter closes. Whether the firm loses fewer clients is a question for the dashboard in six months. Whether the firm can now see a client being lost is settled.

References

Bitner, M. J., Booms, B. H., & Tetreault, M. S. (1990). The service encounter: Diagnosing favorable and unfavorable incidents. Journal of Marketing, 54(1), 71–84. https://doi.org/10.1177/002224299005400105

Homburg, C., Jozić, D., & Kuehnl, C. (2015). Customer experience management: Toward implementing an evolving marketing concept. Journal of the Academy of Marketing Science, 45(3), 377–401. https://doi.org/10.1007/s11747-015-0460-7

Payne, A., & Frow, P. (2005). A strategic framework for customer relationship management. Journal of Marketing, 69(4), 167–176. https://doi.org/10.1509/jmkg.2005.69.4.167

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

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 perform the work described here. The build counts are drawn from the approved specification and from the portal itself. No business outcome is claimed, and the reason no business outcome is claimed is stated in the limits section rather than omitted.

Acknowledgments

The specification was reviewed and approved by the firm's owner, its operations lead and its technical lead before the build began. The data-quality remediation running alongside the build was performed by the firm's own operations team.