An Aged Care Deal Pipeline Built Around the Family Enquirer
A family-owned residential aged care provider took roughly fifteen enquiries a month, tracked in a physical folder with no record of where each stood. The caller was almost always a family member, never the resident who would move in. We built an internal HubSpot form that creates a Contact for the caller and a Deal for the resident in one submission, and the deal moves through a five-stage pipeline with its own task automation.
Executive Summary
Context
The provider runs two residential aged care homes in regional Victoria, with a third due to open, and had no CRM before this build: enquiries ran through a shared inbox and a paper checklist.
What We Built
We built an internal Resident Enquiry Form that creates a Contact and a Deal in one submission, replacing a paper-based follow-up process with a five-stage deal pipeline and deal-stage task automation.
Tech Stack
- HubSpot Marketing Forms
- HubSpot Deal pipelines
- HubSpot Workflows
- HubSpot reporting dashboards
Not a fit if your enquiry volume needs volume-based marketing automation rather than a staff member keying in each call by hand, since this pipeline assumes a small team entering every enquiry itself. It also assumes you can hold off connecting a clinical system until a later phase.
The Challenge
Before this build, a family member calling about a room got a phone conversation. If they toured or applied later, the follow-up lived in a folder rather than a CRM. The provider had just bought its first HubSpot Sales Hub Professional licence, and the form had to solve a problem specific to aged care.
The caller is a family member acting for someone else, and several relatives with different legal authorities, such as Financial or Medical Power of Attorney, might need tracking against the one resident. HubSpot's contact record maps to the person submitting a form, not the person it is about. And because of the provider's privacy concerns, a full contact record for a resident who hadn't agreed to anything wasn't an option.
Our Approach
We started from the way most HubSpot rollouts treat a lead: one form, one new contact. That breaks once a second relative calls about the same resident, or the caller is a referring doctor, because HubSpot doesn't have a native way to say that two contacts act for one resident who isn't a contact at all.
The Resident Enquiry Form instead creates a Contact for whoever lodges the enquiry and a Deal carrying the resident's details as deal properties. A Role field set to multi-select lets Financial POA, Medical POA, Personal Matters and Primary Contact sit on one record. Two required fields, how the family heard about the home and the planned move-in date, gate the form, and the deal name carries the resident's name and location.
The deal advances through five stages, Lead, MQL, SQL, Opportunity and Customer, with task automation on each change. The trade-off is that nothing here talks to the clinical system. We held that for a later phase so the object model could be settled first.
Impact
A single view of every open enquiry
Because every enquiry becomes a deal on one pipeline, a manager can see how many sit at Lead, have toured, or wait on an application, without checking a folder. That view was the roadmap's own dashboard deliverable.
A record that survives more than one relative calling in
Multi-select role fields let Financial POA, Medical POA, Personal Matters and Primary Contact sit on one relative's record, and a second relative calling about the same resident joins the existing deal instead of creating a second resident record.
A required-field gate that gives sales what it needs to triage
The form won't create a deal until a staff member enters the two required fields, so every deal reaching the pipeline already carries what a rep needs to triage it.
A phased boundary that keeps the clinical system out of the first build
Deferring the clinical resident-management system to a later phase meant the pipeline only had to model sales data, without anticipating a second system's fields. That was a deliberate scope decision rather than a limitation.
A staff-facing form completed during a phone or walk-in enquiry rather than filled in by the public online. Submitting it creates a Contact for the caller and a Deal for the resident in one action, gated by two required fields.
A five-stage deal pipeline, Lead, MQL, SQL, Opportunity and Customer, advancing on a completed form, a booked tour, a submitted application and an approved application. Task automation fires on each stage change.
A Role property on the contact set to accept more than one value, so Financial POA, Medical POA, Personal Matters and Primary Contact can all sit against the one relative acting for a resident.
Resident details live as deal properties rather than a second contact record, so the family member who lodged the enquiry stays the one contact HubSpot tracks, reflecting the provider's privacy stance.
The caller is a family member, but the enquiry is about a resident who hasn't agreed to anything. HubSpot's contact record maps to whoever submits a form, so it can't describe the resident. Now one submission creates a Contact for the caller, with a multi-select "Role" property, and a Deal that carries the resident's details. A second relative calling in no longer forces a duplicate contact.
FAQ
Because the person lodging an aged care enquiry is almost never the person who will live in the home, treating both as contacts would create a record for someone who hasn't agreed to anything. Deal properties track the admission decision without a second contact.
The provider's enquiry volume, roughly fifteen a month, is low enough that a staff member can complete the form during the call itself, capturing detail a web form would miss, and confirm the two required fields in conversation rather than leave them blank.
