Product Usage Scoring & Routing
An explainable weekly Sales and Customer Success routing system that separates fit, product usage, and buying intent, then syncs one approved action to HubSpot.
Project overview · 41 seconds
The weekly Sales and CS queue often explains nothing
The starting point is a revenue problem, not a technology one. Product behavior exists — logins, incidents, pricing pages, security docs — but the weekly Sales and Customer Success queue can still be late, noisy, over capacity, or unexplained.
A team looking at a routed account usually cannot answer four basic questions: why did this account enter the queue, who should act on it, how fast, and what changed versus last week? A single opaque score turns routing into a black box the team must trust without being able to inspect.
This case study demonstrates an alternative: an explainable weekly routing intervention. It uses fictional data so a prospective client can inspect the method without mistaking it for a real company’s results.
One combined score is often the wrong abstraction
Separate the signals before scoring.
Fit, product usage, and buying intent are different questions. Collapsing them into one number hides which signal actually moved an account, and it hides the tradeoffs the business is making.
Use gates, not just scores, before any human action.
A score ranks; gates decide. Hand raiser, acquisition sales-assist, monitor, self-serve, manual review, and expansion are visible routes decided by explicit rules, with an owner and a real SLA attached.
The same accounts under two policies
The demonstration runs the same 120 synthetic accounts through a naive combined score and an explainable gated policy at the same weekly human-action capacity. The queue makes the difference visible, and the synthetic metrics never claim to show real business efficacy.
The comparison is illustrative, not a claim that one policy predicts better than the other. The naive queue’s 100% routed yield at the default capacity of 12 is a small-sample artifact: all twelve routed accounts happen to carry a synthetic positive outcome, so the naive precision and yield numbers therefore say more about the sample than the policy. The gated policy provides context-specific plays, hard blocks, ownership, SLAs, rejected alternatives, and explainability. It is not designed to win a metric contest. The numbers are exactly as computed at the default controls; nothing is tuned or hidden to make either side look better.
The naive comparator is transparent
The naive policy, combined_score_naive_v1, is a simple baseline. It collapses fit, product usage, and buying intent into one number, roughly a weighted average, then routes any account above a single threshold into one generic Sales queue. It has no hard blocks, no prospect-versus-customer distinction, and no separate plays.
It is not a claim about any real company’s former policy. It keeps the comparison honest and easy to read: one number can be the wrong abstraction, and this page shows why.
Every route carries a decision packet
The gated policy scores each account on three separate 0–100 dimensions and evaluates visible gates before routing. An account’s decision packet shows the full record: identity, a product-event timeline, the itemized points behind each score, which gates passed or failed, the strongest rejected alternative, the owner, the SLA, and the current CRM state.
Two levers, live recompute
Visitors can change exactly two allowlisted controls: the acquisition intent minimum and the weekly human-action capacity. Changing capacity reprioritizes the queue but never changes whether an account qualifies. Qualified overflow stays visibly deferred. The policy view makes the tradeoff between intent and team capacity concrete.
The bounded HubSpot approval and sync
The demonstration includes one bounded external write. A designated account’s decision packet offers an “Approve and sync” action that creates a single fictional follow-up task in a dedicated HubSpot developer test account. It never sends outreach or email and never changes real customer data.
The sync is idempotent and traceable to a run id: identity is resolved, scores are recorded, a play is selected, and the durable workflow upserts a fictional company, contact, and association and creates one task. A fake local adapter keeps the full demo usable without any credentials, while a hardened production path runs the same workflow on Cloudflare with the real HubSpot adapter.
The real adapter was verified end to end against the dedicated HubSpot developer test account on 2026-08-14, with fictional data only: the designated account synced as a company record carrying the usage_routing properties, the associated contact, and one follow-up task, and reruns returned the same external identifiers without duplicating records or tasks. A read-only company-record app card is installed on that test account and reads the latest scores, signals, and gates back from an authenticated Cloudflare endpoint that fails closed without a valid signature.
Cloudflare is the decision and execution layer
Pure decision engine, validated at runtime.
Scoring and routing are pure, table-tested functions that import no Cloudflare or HubSpot code. All boundary data is validated at runtime, and timestamps are stored in UTC ISO 8601 and rendered in the viewer’s locale.
Durable execution, not just a request.
The approve-and-sync path runs as a Cloudflare Workflow over D1 state: run and signal records persist, the workflow is idempotent and retryable, and a completed run survives a refresh via its opaque run id.
HubSpot stays the operational destination.
Cloudflare owns the decision and execution; HubSpot is the CRM destination. The app card reads latest scores, signals, and gates back from an authenticated Cloudflare endpoint, so the CRM record and the decision stay connected.
Synthetic data, stated clearly
Every person, company, domain, event, and outcome in the demonstration is fictional. Northfield Software and its Northfield Incident Management product exist only to supply believable product signals. Synthetic CRM contacts omit email entirely and are identified by name plus a unique person id, so no email of any kind is written to HubSpot.
The scores, gates, and outcomes are expert-defined demonstration hypotheses, not validated predictors. The app states this on the queue, the policy view, and the About page. Precision, recall, and yield demonstrate the method only and are never presented as real business efficacy.
I owned the decision system end to end
I designed and built the full system as an independent project: the product concept, scoring and routing policy, weekly queue and decision-packet experience, adjustable controls, Cloudflare Workers + D1 + Workflows execution layer, and bounded HubSpot integration with its app card and fake local adapter.
The outcome is a live, login-free demonstration a prospective client can inspect end to end — from a raw product signal to an explainable route with an owner and SLA, and one bounded, idempotent write into HubSpot.
What the demonstration delivers
The demonstration connects product behavior to explainable revenue action and HubSpot operations without an opaque universal score, and it makes every limitation explicit.
The same accounts route differently and legibly.
120 synthetic accounts produce distinct, explainable outcomes under a gated policy and a naive combined score at the same weekly capacity.
Every route explains itself.
Each account shows identity, product-event timeline, fit/usage/intent scores, gates, rejected alternatives, owner, SLA, and CRM state.
Intent and capacity recompute the queue live.
Visitors change the acquisition intent minimum or weekly human-action capacity and watch who enters or leaves the queue.
One approved action stays idempotent and fictional.
An approved action creates a single follow-up task in a dedicated HubSpot test account — never outreach, no email, no secrets exposed.
Inspect it, then ask about your own workflow
The live demo runs the same 120 synthetic accounts through both policies, shows the decision packets, and lets you change intent and capacity. The source is public and includes the spec, the durable workflow, the HubSpot adapter, and the full test suite.
Open the live demo
View source on GitHub →
If product or customer signals are reaching HubSpot too late — or without enough context — I can review one workflow and return a written map of the leaks, risks, and the smallest useful fix.
Request a written GTM systems assessment
Have a product priority that needs an owner?
I join B2B SaaS teams on contract to ship the features, internal tools, and integrations already on your roadmap.