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
Product Usage Scoring & Routing overview
A short overview of the problem, solution, and result.
Starting Point
Product behavior often exists, but the weekly Sales and Customer Success queue arrives late, noisy, over capacity, or unexplained. One combined score collapses fit, product value, and buying intent into a single opaque number, so the team cannot tell why an account was routed or who should act.What Shipped
An explainable weekly Sales and CS routing queue comparing a gated policy and a naive combined score on 120 synthetic accountsWhy It Mattered
The demonstration makes the weekly Sales and CS routing decision visible: the same 120 accounts produce different, explainable outcomes under the gated policy and the naive comparator.The weekly Sales and CS queue often explains nothing
The starting point is a common 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 the basic questions: why did this account enter the queue, who should act on it, how fast, and what changed versus last week? When the answer is a single opaque score, the routing becomes a black box that the team has to trust without being able to inspect.
This case study is a live demonstration of an alternative: an explainable weekly routing intervention. It is built with fictional data on purpose, so a prospective client can inspect the method without it being mistaken 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 identical 120 synthetic accounts through a naive combined score and an explainable gated policy at the same weekly human-action capacity. The difference is legible in the queue, and the synthetic metrics never claim to be 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 say more about the sample than about the policy. The gated policy is designed to provide context-specific plays, hard blocks, ownership, SLAs, rejected alternatives, and explainability — not 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 deliberately simple baseline: it collapses fit, product usage, and buying intent into one number — roughly a weighted average — and 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 exists so the comparison is 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 — it 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 — never outreach, never an email, never a change to 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.
What I owned
I designed and built the full system as an independent project: the product concept, the scoring and routing policy, the weekly queue and decision-packet experience, the adjustable controls, the Cloudflare Workers + D1 + Workflows execution layer, and the 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
Implementation details
Have something that needs building?
I build customer-facing features, internal tools, and integrations for B2B SaaS teams on contract.