top of page
< Back

Fuse

A conversational fleet assistant, built on the Claude API, that turned dashboard-reading into ask-and-answer — going from a sales demo script with no backend to recommendations with real dollar figures trusted by AT&T, Bridgecrest, Hyundai Capital, and a dozen other fleet customers.

Fuse turned fleet questions into conversations.

Product Case Study · Motorq

In under a year, Fuse went from a sales demo script with no working backend to a conversational assistant generating recommendations with real dollar figures attached — read, trusted, and acted on by fleet managers at AT&T, Bridgecrest, Hyundai Capital, and a dozen other customers.

  • Oct 2025 — first artifact

  • Aug 2026 — current state

  • Built on Claude API

01 · Need — Before Fuse, the answer was a spreadsheet

Motorq's fleet platform already had the data — Snowflake views full of vehicle and telemetry history, a TCO Dashboard, a Portal. What it didn't have was a way to just ask. Customers still did the last mile of analysis themselves.

Manual work — Excel was the real interface. When AT&T needed every VIN that hadn't reported in 30 days, their own contact ran it manually in Excel — the dashboard could show the data, but not answer the question directly. That gap is what Fuse was built to close.

Existing surface — The Portal + TCO Dashboard. Visibility already existed — dashboards, charts, reports. What was missing was a conversational layer on top of data that was already there, not a new data platform underneath it.

GTM before engineering — The pitch existed before the product. The oldest surviving artifact in the whole record is a sales demo script (Oct 2025) — tiered prompts across four domains, built to show off conversational fleet Q&A before the backend that would answer those questions was production-ready.

02 · Approach — Ship narrow, trust before you automate

Every early scoping decision leaned the same direction: constrain the surface area first, prove it's trustworthy, then widen it. That discipline is the throughline of the whole product.

Voice, deliberately narrow — Skim the top, don't replace chat. Fuse Voice Assistant was scoped to aggregated insights only — anything over 10 rows redirects to the full chatbot. It was never meant to be a complete surface on its own.

Recovery, read-only first — Awareness before action. Fuse's access to vehicle recovery context was scoped as strictly read-only, gated behind specific roles (recoveryFMC, recoveryLender, Fuse Admin) and rolled out tenant-by-tenant — Bridgecrest, Hyundai Capital, Stellantis Financial — rather than switched on globally at once.

Fuse Watch posture — "Recommend and notify," not "recommend and act." Even the proactive monitoring product was built to backtest against historical data before ever going live — a deliberate trust-building step before letting an autonomous monitor run unattended.

"Fuse must not silently substitute a proxy metric for one it doesn't actually have." — operating principle behind LLM-660, "Fuse Assistant – Quality & Trust Foundation"

03 · Build — One PRD, nine months, a real agent roster

The parent document — [Portal] PRD Fuse Phase 1 & 2 — went through 56 revisions across nine months, confirming Fuse runs on the Claude API and defining every term and metric every later doc inherits.

Data layer. VEHICLES_VIEW, TELEMETRY_VIEW, fleet snapshots — the Snowflake substrate every downstream skill (Recovery, Watch, Rec Engine) queries against.

Agent roster. Remarketing · Replacement · Utilization · Maintenance · Efficiency · EV · Safety · Compliance · Recovery — grouped into Cost/Asset, Operations, and Risk/Compliance clusters.

Surfaces. TCO Dashboard → Action Hub → Fuse Insights → Fuse Assistant — visibility, structured recommendations, and open-ended chat, with an explicit rule for which question belongs where.

Real data, early. Sasser production reports — even in the earliest period, Fuse generated output grounded in a live customer's actual fleet, across four report types with real savings estimates.

04 · Pilot — Trust gets built one wrong answer at a time

Real customer data surfaced real failure modes. What matters is what happened next: every miss became a tracked ticket, an RCA, and a fix — the mechanism, not just the incident.

LLM-629 — A hallucinated root cause. Fuse invented a plausible-sounding explanation for a Ford telematics gap it had no real data on. Root cause: it filled a context gap with fabrication instead of admitting the gap. Fixed by making Fuse explicitly say when a question is outside its scope.

DIS-49070 — 265 vehicles, wrongly flagged. An AT&T contact's manual Excel count disagreed with Fuse's own answer on non-reporting vehicles. The single complaint seeded a standing pattern-review process (DSA-2841) for catching this class of bug before customers do.

DIS-50193 — 2,829 vehicles that weren't missing. Fuse had no visibility into the Enrollment Dashboard it was being asked about — every "missing" VIN was actually an enrollment attempt that never succeeded. Six engineers, one RCA, one fix: give Fuse the context it was missing, or teach it to say it doesn't have it.

AS-7308 – AS-7324 — Five bugs, two reopened. Formal test plans against a golden set caught real mismatches — a wrong crossing date, inconsistent rounding, a broken chart link, contradictory lease-cap answers. Two bugs marked "fixed" were reopened days later, tracing back to upstream data disagreeing with itself, not just Fuse being wrong.

"[Bridgecrest] had no idea what a 'day time recovery recommendation' was." — Marshall Hawley, customer feedback on LLM-624; traced back to Recovery only being enabled in the Hyundai Capital environment at the time — a scope gap, not a defect.

05 · Impact — From answering questions to generating recommendations

Six recommendation types shipped against one hard deadline. A closed-loop enrollment product started paying down support volume directly. The demo script stopped needing synthetic numbers.

Figures: $9,216 Freightliner utilization swap · $421 Corolla oil-change recommendation · $194 ProMaster idling-cost flag · 84 vehicles in one live disposal report demo.

Apr 9–13, 2026 — Six recommendation types, one deadline. Idling, oil change, DTC/service warning (5,779 unique codes triaged into S1–S5 severity), tire pressure, and two lease-vehicle rebalancing types — coordinated across Product, Engineering, DS, and UI in an 85-revision tracker.

Light-Me-Up — 262 self-serve requests/month, 40% of support volume. A narrow agent built specifically to close enrollment and NRV loops — approval-plus-audit-trail as the core value proposition, not raw automation.

Fuse Watch — Named demand from 11 customers. Hilti, Stellantis, AT&T, SFS, Bridgecrest, Mike Albert, Leon County, Element, Barco, Powerfleet, Sasser — proactive monitoring requested by name, not speculative roadmap.

06 · Next — What's still open

Not every gap is closed. The roadmap is prioritized, not aspirational — and two recommendation types are still blocked on the same missing data source.

P1 — Enrollment Logs Skill, Chat History / Memory, Portal Context. P1.5 — Data Services, Platform Context. P2 — OEM / Aftermarket specifics.

Two shipped recommendation types — rebalancing over-utilized lease vehicles and right-sizing under-utilized ones — remain blocked on an undetermined 3rd-party lease-data source. The second also carries an open product question nobody has answered yet: what should a customer actually do with a vehicle flagged as under-utilized?

A separate proposal is already exploring what memory and file-upload could add — distinguishing Structured Data Ingestion (known schema, e.g. fuel cost sheets) from Contextual Data Ingestion (variable schema, e.g. a one-off VIN list for an investigation), with Fuse learning column mappings on recurring monthly uploads.

Sourced from the Fuse Confluence corpus (Oct 2025 – Aug 2026) and 17 linked Jira tickets across LLM, DIS, AS, and DSA.

Power in Numbers

262

Programs

40

Locations

9216

Volunteers

Project Gallery

© 2026 BY VISHNU PRIYAN A J. ALL RIGHTS RESERVED

bottom of page