← Prototypes·Customer health score — v2 proposal
DETMUSNATSPD
DM
Detroit Muscle Speed Shop
DETMUS \u2014 2 seats, 2 active \u2014 Mature tenant
Score: 52 \u2014 At risk
Detroit Muscle is a small but active 2-person shop that's been hit by a sharp activity drop in the last 30 days, likely driven by frustration with a telephony Hotfix bug that affected their SMS workflows. They're still processing payments and creating work orders, but their engagement pattern has shifted \u2014 they went from steady daily usage to sporadic bursts. Joey called them today. This account needs a quick follow-up to confirm the Hotfix resolved their issue and rebuild confidence.
What's concerning

Their weighted activity dropped 80% compared to the prior 30-day period. For a 2-person shop, this is a significant signal \u2014 both users are still active, but they're doing less in the system day-to-day. The likely trigger is SPD-1461, a Hotfix-priority bug reported March 26 where SMS sends from quotes and WO checkouts were routed through the wrong telephony provider, breaking their customer communication workflow. This bug has been resolved and deployed, but the activity dip suggests it may have disrupted their routine.

Activity trend: -80%Only 4 of 10 sticky features used1 Hotfix bug in 90 days (SPD-1461)
What's healthy

Despite the activity dip, both users are still logging in and working. They created 12 work orders in the last 30 days (up from 9 the prior period \u2014 a 33% increase), which means the core business is growing even if overall platform usage dropped. Payments are strong: 44 processed in 30 days vs 11 the prior period. They were last active yesterday. This isn't a disengaged tenant \u2014 it's a frustrated one that needs the friction removed.

WO throughput: +33% (12 vs 9)Payments: 4x increase (44 vs 11)Seat utilization: 100% (2/2)Last active: 1 day ago
Communication history

Joey called today (Apr 2). Most recent substantive call was Mar 31 where a customer reported 2 bugs with their new phone number \u2014 calls weren't routing correctly and declining a call created over 100 phantom leads. The previous call on Mar 31 was about QuickBooks sync pricing discrepancies (resolved by walking them through the reconciliation guide). Call volume is moderate (3\u20134 calls in the last week) which is typical for a tenant working through new-feature friction.

Last call: today (Joey)Recent calls about bugs, not training

Recommended next steps:

1. Confirm SPD-1461 (Telnyx SMS routing) is working correctly for their account \u2014 have them test sending an SMS from a quote page.

2. Address the phantom leads issue from the phone bug \u2014 they may need help bulk-deleting the 100+ auto-created leads.

3. They're only using 4 of 10 feature areas \u2014 missing scheduling, POs, time tracking, shipping, documents, and approvals. Not urgent, but a good expansion conversation once the bugs are cleared.

Generated Apr 2, 2026 \u2014 based on activity_log, work_order_payments, Notion tickets (SPD-1461), and Close CRM call history. Score components: Usage 60, Trend 30, Finance 85, Features 40, Support 35, Engagement 55.

Score components

Product usage (35%)
Measures the intensity of real work happening in the ERP, scoped to the features the tenant has actually adopted. This component answers: "Given what they use, how actively are they using it?" It never penalizes a tenant for features they haven’t adopted — that’s the job of Feature Adoption.
▸Active user-days — COUNT(DISTINCT causer_id, DATE(created_at)) from activity_log. A 2-person shop with 20 user-days/month means both users are in the system ~10 days each.
▸Seat utilization — active users / total enabled users. Measures what percentage of the team actually touches the system.
▸WO engagement — three sub-metrics that replace the old simple WO-created count: (1) WOs created measures new business intake, (2) distinct WOs edited measures breadth of active work — this catches restoration shops that create 3 WOs but work on 25 of them for weeks, and (3) WO-related edit density (parts added, labor ops updated, payments processed) measures the depth of work happening on each order.
▸Action density — total actions per user-day. Distinguishes someone who opens the app once from someone who lives in it all day.
Activity trend (15%)
Captures whether the tenant’s engagement is stable, growing, or declining — scored against the tenant’s own historical baseline, not against a growth target. A fully-adopted tenant whose activity holds steady at their normal level scores near-maximum. The goal state for a mature tenant is stability, not perpetual growth.
▸Per-tenant baseline — the tenant’s 90-day rolling average of weighted activity becomes their personal baseline. All trend scoring is relative to this number, so a 2-person shop at 300 actions/week and a 14-person shop at 6,300 actions/week are both measured against their own normal.
▸Stability band scoring — activity within ±15% of baseline scores 85–100 (this is the healthy steady state for a mature tenant). Above +15% scores 100 (growing — good, but not meaningfully better than stable). Between -15% and -40% below baseline, the score drops from 85 toward 40 (real decline starting). Below -40% scores under 40 (something has fundamentally changed).
▸Business-day inactivity — days since last activity counted in business days only (excludes weekends). Critical threshold at 14+ business days, not the current system’s 7 calendar days which falsely flags holiday weeks.
▸WO throughput trend — WOs created this period vs prior, as a secondary signal to detect whether new business is flowing in or drying up, independent of overall activity noise.
Design principle: stability is the goal state. A tenant like NATSPD fluctuating between 5,800 and 6,900 actions/week is perfectly healthy and should score 85–100 on trend. The old model would have scored this as "flat" or "slightly declining" — the baseline-band approach recognizes it as exactly where a mature tenant should be.
Financial health (10%)
Tracks whether the tenant is processing payments through the system. Intentionally lower-weighted because payment drop is a lagging indicator — by the time payments stop, the tenant has already disengaged.
▸Payment recency — days since last processed payment. Relaxed threshold: critical at 30+ days to accommodate shops that batch weekly or biweekly.
▸Payment volume vs baseline — 30-day total compared to tenant’s own 90-day monthly average, not a fixed dollar threshold.
▸Finix/checkout integration — whether they’re actively using Speedpoint’s payment processing via checkout sessions. Creates significant switching costs.
Feature adoption (15%)
The single home for measuring how deeply embedded Speedpoint is in the tenant’s operations. This is where breadth (how many features) and depth (how deeply integrated) are scored. A tenant that hasn’t adopted a feature is only penalized here — never in Product Usage or any other component.
▸Sticky feature checklist (10 areas) — binary active/inactive for: work orders, quoting, scheduling, purchase orders, payments, time tracking, leads, shipping, documents, approvals. Each scored from activity_log subject matches in the last 30 days.
▸Shop floor penetration (additive bonus, never penalizes) — a graded bonus for tenants that have adopted labor time tracking. Measures: tech adoption ratio (distinct techs clocking / total users), WO clock coverage (distinct WOs clocked / total active WOs), and labor log volume (hours/month). A tenant with zero labor logs simply gets no bonus here — they are NOT penalized twice. A tenant like NATSPD with 4 techs clocking 539 hrs across 62 WOs gets a meaningful boost because that level of shop floor integration represents dramatically higher switching costs. Only ~3 of 30+ tenants currently use labor logging.
▸Integration depth — whether the tenant has adopted platform services: Finix payment processing, Telnyx/Twilio telephony, QuickBooks sync, and the customer portal.
▸Advanced feature usage — activity in newer capabilities: checklist submissions, document templates, entity approvals.
Design principle: no double-counting. If a tenant hasn’t adopted time tracking, they lose points once in the feature checklist (4/10 instead of 5/10). They are NOT also penalized in Product Usage for having zero labor logs. Product Usage measures intensity of what’s used; Feature Adoption measures breadth and depth of what’s been adopted.
Support health (15%)
Gauges product experience quality by analyzing bug ticket history from the Notion issues database.
▸Production bug count — bugs filed against the tenant in 90 days, identified by tenant code in the "Customer / Team" field.
▸Priority-weighted score — Hotfix = 5, Critical = 4, High = 3, Medium = 2, Low = 1. Higher severity bugs carry more weight.
▸Open/unresolved bugs — count of bugs still in non-complete statuses. Each unresolved bug applies an additional penalty; any open Hotfix or Critical sitting 14+ days tanks the score.
▸Resolution velocity — average days from "Reported On" to "Done Date". Fast resolution (same-day Hotfix fixes) partially offsets high bug volume.
Engagement (10%)
Measures the communication relationship between Speedpoint’s team and the tenant. For a sticky ERP, lower communication generally means a healthier tenant — they’re self-sufficient.
▸Call volume and direction — outbound (Speedpoint-initiated) and inbound (tenant-initiated) calls from Close CRM in the last 90 days. High inbound volume may signal frustration; high outbound with low usage may signal disengagement outreach.
▸Days since last contact — how recently the success team has been in touch.
▸Usage cross-reference — the critical nuance. Low communication + high usage = "happy silence" (score 100). Low communication + declining usage = "giving up silence" (the most dangerous churn pattern). This cross-reference prevents the score from penalizing healthy self-sufficient tenants.
▸Lifecycle stage — onboarding (< 90 days), established (90 days–1 year), mature (> 1 year). Higher communication volume is expected and healthy during onboarding; thresholds adjust accordingly.