About this demonstration

The problem

Product behavior exists, but the weekly Sales and Customer Success queue is late, noisy, over capacity, or unexplained. One lead score is often the wrong abstraction: it collapses fit, product value, and buying intent into a single opaque number.

The intervention

Product Usage Scoring & Routing is an explainable weekly routing application. It separates fit, product usage, and buying intent; applies visible gates before any human action; routes the right accounts to the right owner with a real SLA; and compares the same accounts under a naive combined score so the difference is legible.

Northfield Software is the fictional vendor and Northfield Incident Management is its fictional product, supplying believable product signals. The primary surface is the weekly routing queue in the Work Queue.

Method

Every account is scored on three separate 0–100 dimensions — fit (ICP and firmographics), product usage (Northfield signals), and buying intent (pricing, SSO, security, and admin activity) — under a deterministic, versioned policy (northfield_v1). Before any human action, visible gates pick a context-specific play: hand raiser, acquisition sales-assist, monitor, self-serve, manual review, or expansion — each with an owner persona and SLA. The naive comparator (combined_score_naive_v1) collapses the same scores into one number and routes any account scoring at least 60 into a single generic Sales queue, with no gates, no hard blocks, and no prospect/customer distinction.

The 120 synthetic accounts (80 prospects, 40 customers) are generated from a fixed seed. Latent fit, realized value, and commercial readiness are drawn first; observable attributes and events derive from them; outcomes are sampled from the latent variables plus bounded noise — never from the displayed policy. The precision, recall, false-positive rate, and routed-yield metrics in the queue and Policy views compare those methods on the same accounts and capacity.

Architecture

TanStack Start app on Cloudflare Workers
  -> Worker API
  -> pure decision-engine package
  -> D1 audit/state
  -> Cloudflare Workflow
  -> HubSpot company/contact/owner/task

HubSpot company card
  -> authenticated Cloudflare endpoint
  -> latest scores, signals, gates, and run link

Cloudflare is the decision and execution layer: the Worker API persists runs to D1 and triggers a durable, idempotent Workflow that syncs the designated fictional account to HubSpot. HubSpot is only the operational CRM destination. Locally and in the preview the sync runs through a deterministic fake adapter — the real HubSpot test account is used only when write credentials are configured.

HubSpot proof

One designated action — Approve and sync — persists a run and executes the fictional company, contact, association, and follow-up task through the configured HubSpot adapter. It is idempotent (reruns never duplicate records), creates a task only when the play requires one, and never sends outreach. Synthetic contacts omit email entirely and are identified by fictional name plus a unique usage_routing_person_id. The read-only HubSpot company card authenticates against the same application state; the Routing Log shows the truthful pending/completed CRM states.

All CRM records live in a dedicated HubSpot developer test account and contain fictional data only. No HubSpot tokens, portal identifiers, or external ids are exposed to the browser or the repository.

Limitations

All people, companies, usage, and outcomes are fictional or synthetic.

• Scores, gates, and outcomes are expert-defined demonstration hypotheses, not validated predictors — never real business efficacy.
• The synthetic outcome comparison is illustrative. The naive queue’s routed yield at the default capacity of 12 is a small-sample artifact, not evidence the naive policy is better.
• The gated policy is designed to provide context-specific plays, hard blocks, ownership, SLAs, rejected alternatives, and explainability — not to claim universal predictive superiority.
• The naive comparator is a transparent educational construct, not a claim about any real company’s former policy.
• There is no authentication, no real incident data, and no outreach: the sync creates one fictional task at most.

Source

Public repository: github.com/HanifCarroll/product-usage-scoring-routing. Published case study: hanifcarroll.com/case-studies/product-usage-scoring-routing.

Authorship and next step

Designed and built by Hanif Carroll as proof that product behavior can be connected to explainable revenue action and HubSpot operations — without an opaque universal score.

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.