Persona-based HubSpot lead routing with stage-tuned stagnation alerts
A compliance-literate B2B buyer answers one question on the contact form: which option best describes you. That single field had to sort five different audiences into five different lists, while a stalled support ticket or deal could go unnoticed for weeks. We built a routing fork keyed to that answer, plus two independently-scheduled stagnation alerts to Slack, one for tickets and one for deals.
Executive Summary
Context
The client runs a blockchain-based financial-messaging network built to ISO 20022 payment-messaging standards, selling into financial institutions evaluating a compliance-literate B2B product. Five distinct buyer roles, from a technical evaluator to a non-buying community member, arrived through the same contact and demo forms.
What We Built
We built a persona-answer routing fork on the contact form into five lists, plus two independently-scheduled stagnation-alert pipelines, one for tickets and one for deals, each posting to Slack on its own threshold.
Tech Stack
- HubSpot Marketing Hub
- HubSpot Sales Hub
- HubSpot Service Hub
- Slack
Not a fit if your team can't commit one consistently available contact to approve routing destinations as they change: this build depended on a single named point of contact for planning and threshold decisions. It also assumes contact and deal data already live in one CRM, since a property tracked in a separate system can't drive a Slack alert from here.
The Challenge
The client had a single contact-form question, which option best describes you, and it had to sort an evaluator from a technical lead, a job applicant and a member of the network's own public community. Each of those needed a different follow-up path.
Support tickets and sales deals also had a habit of stalling in a middle stage. A ticket could stay in Assigned or In Progress unchecked, and a deal could stay in Demoed or All parties engaged well past the point a rep should have followed up. These stalls lasted long enough that a prospect or customer gave up asking.
The properties that showed this already existed on each record. What was missing was a rule that read them on a schedule and flagged when the time ran out.
Our Approach
The routing is a single fork. The contact form's persona-answer property decides the destination, placing each submission into one of five lists, or into a Support/Legal path when the answer marks the contact as outside the buying audience. We used two separate schedules for stagnation detection instead of one shared rule, because a ticket and a deal fail differently.
The ticket pipeline re-enrols every record in Assigned or In Progress every 15 hours, and posts to the support Slack channel if the stage hasn't moved. It escalates again once a ticket reaches 30 days in On Hold. The deal pipeline instead keys its check to the current stage: seven days in New, seven in Demoed, twenty-eight once a deal reaches All parties engaged, and three months in proof of concept. Each threshold posts its own Slack alert.
A simpler rule splits demo-request submissions by whether the contact already carries an open deal. That way a first-touch request and one already mid-pipeline never share a follow-up queue. The trade-off is that the destinations and thresholds are fixed rules, so someone has to approve changes to them as they shift.
Impact
Five buyer types reach the right queue without manual sorting
A single persona-answer field now decides where a record lands, so an evaluator, a technical lead, a role candidate, and a community member never share a queue with a sales-qualified buyer. Anyone outside the buying audience routes straight to Support/Legal instead of waiting in a sales list for manual re-sorting.
A stalled support ticket surfaces before a customer has to ask twice
The ticket pipeline re-checks every record in Assigned or In Progress on a fixed 15-hour cycle, so an untouched ticket posts to the support Slack channel before a customer notices the silence. A ticket left in On Hold past 30 days triggers a second alert, so it never ages out of view unread.
Deal stagnation is caught on a schedule tuned to the stage
Because a new deal, a demoed deal, and a proof-of-concept deal stall for different reasons, the pipeline checks each stage against its own threshold, from seven days in New out to three months in proof of concept. Crossing that threshold posts to the team's Slack channel, so a rep learns a deal has stalled at the point specific to its own stage.
Demo requests split by pipeline status before anyone has to ask
Every demo-request submission now checks for an existing open deal before it reaches a list, so a first-touch demo and one from a contact already mid-pipeline never compete for the same follow-up. That split lets the team message a brand-new contact differently than one already talking to a rep.
A single hidden property reads the answer to the contact form's "which option best describes you" question and writes the record to one of five destination lists, or to a Support/Legal path when the answer falls outside the buying audience. The fork runs once, on submission, with no review step.
A workflow re-enrols every ticket in Assigned or In Progress every 15 hours, checking stage and time-in-stage before posting to the support Slack channel if nothing has changed. A ticket reaching 30 days in On Hold trips a second, separate alert.
The deal pipeline keys its check to the current stage rather than one shared window: seven days in New, seven in Demoed, twenty-eight at All parties engaged, three months in proof of concept. Crossing the relevant threshold posts a Slack alert to the team.
A demo-request form checks the contact's record for an existing open deal before filing it, sorting the submission into a Demo Submission list or a Demo but no deal list. The distinction lets follow-up differ for a contact already mid-pipeline versus one arriving cold.
One contact-form question had to sort five audiences, and tickets and deals could stall in a middle stage for weeks unnoticed. Now a single fork on the persona answer places each submission in one of five lists. The stagnation alerts run on two separate schedules, because a ticket and a deal fail differently. Tickets in Assigned or In Progress are rechecked every 15 hours, each deal stage has its own threshold from seven days in New to three months in proof of concept, and every breach posts to Slack.
FAQ
One property drives it: the answer to which option best describes you on the contact form. That answer writes the contact into one of five lists, or into a Support/Legal path when it marks the person outside the buying audience, with no manual review in between.
A ticket and a deal go stale for different reasons, so one shared threshold would fire too often on tickets or too late on deals. The ticket pipeline re-checks every 15 hours with a 30-day escalation for anything stuck in On Hold, while the deal pipeline sets its own day count per stage, from seven days at New to three months in proof of concept.
