Answer the questions drivers actually ask from your own written policies, stop the moment a driver cites hours, fatigue or a defect, and hand that exchange to a named person.
The exchanges an average under-counts are the fatigue ones — rare enough to disappear fleet-wide, and the ones where being wrong is a 49 CFR 390.6 problem. Nestack reports the hand-off rate by question type, not only in total.
Slice performance — reported separately, not only in aggregateIllustrative example
Slice
Failure rate
Lift
Lift vs. threshold
Status
Fatigue and fitness to drive
6.3%
3.7×
Review
Hours and duty-status questions
3.9%
2.3×
Review
Defect and DVIR questions
2.5%
1.5×
Watch
Routine paperwork questions
1.4%
0.8×
Normal
Bar: hand-off-rate lift vs. routine-paperwork baseline · scale 0–4.0× · tick marks the 2.0× review threshold2 of 4 slices over threshold
Evidence-linked improvement
A person picks it up, then it closes
The loop shuts when the miss is a case in the suite, not when it has been explained. That suite is what the next driver question is measured against.
Improvement cycle · five stagesSwitchback — the path turns at Improve and returns at Learn
01Detect
Hand-off rate rises in a question type.
02Diagnose
The manager who took the exchange reads it back against the policy until one cause holds.
03Improve
Whatever changes ships against a version, with the exchanges that prompted it attached.
04Verify
Nothing ships until the affected cases pass a second time.
05Learn
The suite grows by one case; so does the coercion guardrail set.
Learn → DetectThe return edge. The next detection runs against a suite one case longer.
Typical build scope
Twelve workstreams across six weeks
The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, sources, answering workflow, evaluation, integration, then production validation and handover.
WorkstreamWeek 1Week 2Week 3Week 4Week 5Week 6
01Driver-support workflow discovery and boundary definition.
02Fleet, ELD and channel source assessment.
03Policy, stop-gate and coercion-guardrail rule mapping.
04Question and duty-status ingestion.
05Answering logic and policy binding.
06Confidence scoring and stop routing.
07Manager hand-off workflow.
08Fleet and driver-channel integration.
09Coercion-language cases.
10Guardrails and escalation controls.
11Exchange-trail instrumentation.
12Deployment, documentation and Agent Care handover.
12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallelFinal scope and sequence confirmed in discovery
Engagement tiers
What each tier includes
Rows are the capabilities named in each tier's scope. Higher tiers include everything below them.
Capability✓ in scope · — not at this tierPilotOne terminal, one channelProductionProduction fleet systemsAdvancedMultiple terminals / channels
Introduced at Pilot
Answering from your own policies✓✓✓
Manager hand-off✓✓✓
Answer-quality baseline✓✓✓
Introduced at Production
Reporting by question type—✓✓
Hand-off workflow in your systems—✓✓
Approved write-back—✓✓
Fleet-system integration—✓✓
Introduced at Advanced
Multi-terminal policy sets——✓
Multi-stage escalation paths——✓
High question volume——✓
Multi-terminal support controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build priceConfirmed after discovery based on integrations, workflow complexity, transaction volume, approval controls and deployment requirements.
Separate from buildBuild pricing is separate from recurring Agent Care, which covers managed monitoring, evaluations, incidents and verified improvements after launch.
What we need from you
What you bring, and what we build with it
Each input maps to a piece of build scope and a week in the delivery timeline.
You bringWe build with it
01Your driver policies and escalation paths→Question and duty-status ingestion and policy mappingWeek 1
02Representative past driver exchanges→Answering baseline, policy binding and the stop gatesWeek 2
03Your policy source and your stop rules→Policy, stop-gate and coercion-guardrail rule mappingWeek 1
04Access to relevant APIs, feeds or exports→Fleet, ELD and channel assessment, then integration setupWeek 2
05Answers you would not want a driver to act on→Coercion cases and failure-mode testingWeek 4
06Where an answer must stop and wait for a person→Confidence scoring, stop routing, guardrails and escalation controlsWeek 3
07Named managers to take held exchanges→Manager hand-off workflow, then pilot and production validationWeeks 5–6
Nothing else is requiredDeployment, documentation and Agent Care handover are ours.
Delivery timeline
Four phases across six weeks
The bands follow real work rather than a plan, so evaluation and pilot genuinely share the fifth week.
PhaseW1W2W3W4W5W6
DiscoveryW1
BuildW2 – W3
EvaluateW4 – W5
Pilot & LaunchW5 – W6
Week focusW1Driver-support workflow discovery, policy mapping and the boundaryW2Fleet, ELD and channel integration and the answering baselineW3Answering workflow, confidence logic and escalation controlsW4Evaluation suite, coercion cases and failure-mode testingW5Channel integration, a pilot driver queue and targeted correctionsW6A live driver queue answered under supervision, then Agent Care handover
Reading the bandBars are drawn over the weeks the work occupies. The fifth week doubles because evaluation and launch overlap.
At the end of W6Once the queue validates, Agent Care owns the running agent.
DurationSix-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Transportation AI agent
Build a driver-support copilot that stops where the rule says stop.
Show us your driver policies, your channels and who takes an escalation. Being wrong here is not a poor answer — it is a written record of a driver pressed after saying no, and 390.6(b) gives that driver somewhere to file it.
