Product Case Study

CaseWorthy (formerly Eccovia) · 2023–2025

Food as Medicine:
Last Mile Delivery Integration

Connecting a case management platform with last-mile delivery software to help health and human services organizations deliver meals to vulnerable people — spanning three vendor evaluations, five user personas, and a build-vs-buy journey that transformed reactive one-off integrations into a scalable platform capability.

RoleAssoc. Product Manager, Platform & Integrations
Duration~18 months (iterative)
Who I Worked With

R&D Team (Microservice)

  • 1 Tech Lead (my partner on architecture & API design)
  • 1–3 Software Engineers
  • 1 QA Resource

Solutions Delivery & Customers

  • Implementation Engineers (consuming the microservice, building customer-specific config)
  • Customer stakeholders & end users (discovery, iteration, training)
01 — Context

Why Meal Delivery Mattered

02 — Prioritization & Problem Definition

How We Prioritized This

The signal that this vertical was worth investing in

Pre-existing

Samsara — Already Sold & Implemented

  • Sales had already sold (and the Solution Delivery team had already implemented) a Samsara integration for one customer
  • Essentially one-way: delivery tasks exported to Samsara for route planning — only the dispatcher used it
  • Drivers still on paper, planners still manually prepping kitchen info and driver manifests, still manually tracking missed deliveries after routes completed
  • Integration served a narrow purpose in a heavily manual workflow
First signal

WorkWave — Two Customers, Same Pattern

  • Two more customers wanted fleet integration, both suggesting WorkWave — I led discovery and solutioning
  • Decent dispatch features for planners, but limited driver-facing UX and rough learning curve — most drivers still defaulted to paper
  • Separate implementation teams built slightly different solutions — both took longer than expected given operational complexity and integration challenges
  • Key insight: Despite different org structures, the implementations had a lot of similarities. Working across both, I started recognizing shared problems and needs
Tipping point

3+ More Prospects in the Same Vertical

  • Sales pipeline had 3+ additional prospects in the meal delivery / food-as-medicine vertical
  • Combined with lessons from Samsara and WorkWave, this was the signal: the ROI of productizing core last-mile delivery integration features was worth prioritizing
  • This is when we began formally evaluating WorkWave vs. Onfleet and other potential integration partners
Strategic decision

Onfleet Selected — Superior API, Superior Driver UX

  • Evaluated third-party APIs, features, and lessons learned from WorkWave implementations
  • Onfleet won on API quality (bidirectional, webhook-driven), driver app UX (near-zero learning curve), and integration flexibility
  • Designed a shared microservice with patterns accommodating similarities and differences across customers
Enablement

Org-wide Alignment & Implementation Enablement

  • Established alignment with Sales, Leadership, and Implementation teams on Onfleet as the strategic direction
  • Shifted from reactive, per-customer vendor selection to a proactive platform strategy with reusable patterns
  • Created integration guides and playbooks for implementation teams to deploy independently
  • At departure: one Onfleet deployment in production, two more in progress

The Core Problems

🔄

Dual-system Disconnect

  • Eligibility and dietary needs lived in ClientTrack
  • Route planning and dispatch lived in the fleet tool
  • Changes in one didn't flow to the other
📋

Manual Handoffs Everywhere

  • Planners manually prepared kitchen reports, printed labels, compiled driver manifests
  • Delivery statuses entered manually after drivers returned
  • Every handoff was an opportunity for error
👁️

No Closed Loop

  • Case managers couldn't confirm whether meals were delivered
  • Program managers couldn't report on outcomes
  • The delivery happened in a black box separate from the care record
03 — User Personas & Workflows

Five Personas, Two Systems, One Delivery

🥗

Nutritionist / Dietitian

ClientTrack · Initial Intake & Meal Planning
  • Collected diagnoses (ICD codes) and allergies during client intake
  • Specified meal plans, dietary restrictions, and delivery frequency
  • Clinical inputs determined what the kitchen prepared and what appeared on bag labels
ClientTrack
📁

Case Manager

ClientTrack · Ongoing Coordination
  • Ongoing client coordination: case notes, contacts, program enrollments, service changes
  • Needed delivery confirmation as part of the care record
  • Didn't manage meal plans directly but needed to follow up on missed deliveries
ClientTrack
📍

Dispatcher / Planner

ClientTrack + Onfleet · Prep → Print → Dispatch
  • Used ClientTrack to prepare kitchen reports (meal counts by type) and print bag labels (recipient, diet, allergies, contents)
  • Sent batch of delivery tasks by date and/or region to Onfleet
  • Used Onfleet to optimize driver assignments and delivery sequence per driver
ClientTrackOnfleet DashboardPrinter
🍳

Kitchen Staff

Printed Reports & Labels
  • Received printed kitchen prep report showing meal counts by type
  • Used printed bag labels with recipient name, address, diet tags, allergies, and contents
Kitchen ReportBag Labels
🚗

Driver (Staff & Volunteer)

Onfleet Mobile (or paper route sheet)
  • Onfleet app intuitive enough that new volunteers could start within minutes of a text invite
  • Marked each delivery as completed or missed (with a reason if missed)
  • Could contact recipients and dispatcher when needed
  • Some elderly volunteers still preferred paper, requiring a manual fallback
Onfleet MobilePaper Route Sheet
04 — The Solution

What We Built

Integration Architecture
ClientTrack
Case Management
API Requests →
← Webhooks
Microservice
Orchestration Layer
Onfleet API →
← Webhook Events
Onfleet
Last-Mile Delivery
Scoped API keys for multi-environment isolation · Shared microservice accommodating customer-specific differences

🔑 Environment & API Key Management

One of the less obvious but critical challenges was enabling safe development, testing, and debugging without impacting live delivery operations.

Unforeseen challenge: I underestimated how much time and attention environment management would require. In hindsight, I'd design the multi-environment architecture upfront rather than retrofitting it after realizing we needed safe iteration paths that wouldn't disrupt active meal delivery operations.

Nutritionist — Client Intake & Meal Plan (Mockup)

ClientTrack · Nutritional Assessment
Demographics
Nutritional Assessment
Services
Case Notes
Client
Margaret H. · DOB 04/12/1941
Program
Home-Delivered Meals — Medical
Diagnoses (ICD-10)
E11.65 — Type 2 Diabetes w/ HyperglycemiaI10 — Essential HypertensionN18.3 — CKD Stage 3
Allergies
Tree NutsShellfish
Dietary Restrictions
DiabeticLow SodiumRenal-friendly
Texture
Regular (no modifications)
Meals per Delivery
2 (lunch + dinner)
Delivery Frequency
Monday, Wednesday, Friday
Special Instructions
Leave meals with front desk if client doesn't answer. Client is hard of hearing — knock loudly.

Case Manager — Service Record & Delivery History (Mockup)

ClientTrack · Client Record — Margaret H.
Demographics
Nutritional Assessment
Services
Case Notes

Active Enrollments

ProgramEnrolledStatusFrequency
Home-Delivered Meals — Medical01/15/2024Active3x/week
Wellness Check-in Calls01/15/2024ActiveWeekly

Recent Delivery History

DateMealsDriverStatusNotes
04/232M. Torres (Staff)DeliveredLeft with front desk
04/212M. Torres (Staff)DeliveredHanded to client
04/182B. Chen (Vol.)MissedClient not home
04/162M. Torres (Staff)Delivered
Delivery history visible alongside other services. Missed deliveries flagged for case manager follow-up.

Dispatcher — Kitchen Prep & Bag Labels (Mockup)

Kitchen Prep Report — 04/23/2025

Meal Counts by Type

Meal TypeCount
Regular12
Diabetic8
Low Sodium6
Pureed3
Renal4
Gluten-free2
Total35
Bag Label Preview
Margaret H.
2841 S Highland Dr
Route: East-1
Stop: 3 of 8
DIET
DiabeticLow-NaRenal
ALLERGIES
Tree NutsShellfish
CONTENTS
1× Lunch (Diabetic/Renal) · 1× Dinner (Diabetic/Renal)
⚠ Leave with front desk if no answer

Dispatcher — Delivery Task Batch & Status (Mockup)

ClientTrack · Delivery Task Management

Delivery Tasks

Wednesday, April 23, 2025 · East Region
ClientAddressDietMealsDriverStatus
Margaret H.2841 S Highland DrDiabetic, Low-Na2StaffDelivered
Robert P.1190 E 3300 SRegular1StaffDelivered
Dorothy M.4560 S 900 E, #12Pureed, GF3VolunteerManual Entry
James W.6789 Cottonwood StRenal2StaffIn Transit
Helen K.3321 Murray BlvdDiabetic1VolunteerMissed
Frank L.7200 Bengal BlvdLow-Na, Soft2StaffReady
6 tasks · 3 delivered · 1 in transit · 1 missed · 1 ready

Driver — Onfleet Mobile Experience

New volunteers could start delivering within minutes of receiving a text invite. Drivers marked deliveries as complete or missed (with a reason), and those events fired webhooks back to ClientTrack automatically.

Program Reporting — Delivery Outcomes (Mockup)

Program staff reported on delivery outcomes for program impact, funder requirements, and identifying clients with recurring misses.

ClientTrack · Delivery Program Report

Home-Delivered Meals — Monthly Summary

April 2025 · All Regions
847
Total Deliveries
94.2%
Completion Rate
62
Active Clients
49
Missed Deliveries

Clients with Recurring Missed Deliveries (3+ in period)

ClientMissedTotalRateCommon Reason
Helen K.51258%Client not home
Arthur G.31377%Wrong address
Delivery statuses — whether from Onfleet webhooks or manual entry — fed the same reporting pipeline. Program staff could monitor outcomes regardless of how status was captured.

All mockups are representative. The actual ClientTrack UI used the platform's configurable form designer with API plug-ins.

⚠️ The Volunteer Driver Challenge

Onfleet's app dramatically improved driver adoption vs. WorkWave — but some elderly volunteers still preferred paper. We needed a dual-path approach.

Path A: Onfleet App (Happy Path)

Driver receives text invite, opens app
Follows optimized route w/ navigation
Marks each delivery: ✓ Complete or ✗ Missed + reason
Webhook → ClientTrack auto-updates

Path B: Paper Route Sheet (Fallback)

Planner prints route sheet from ClientTrack
Volunteer delivers with paper list
Returns, reports missed deliveries
Coordinator marks status manually in ClientTrack

Artifacts & Documentation

📄API Keys & Webhooks Integration Guidehelp.eccovia.com

Build vs. Buy: Route optimization, driver apps, and real-time GPS are hard, specialized problems. Our value was connecting case management context — who needs what, with what dietary restrictions, and did they receive it — to the delivery operation. Onfleet's API and UX quality validated this decision repeatedly.

05 — Detours & What Went Wrong

Where Things Got Messy

✅ What Went Well

  • Onfleet's mobile UX solved the driver adoption problem that plagued Samsara and WorkWave
  • Pattern recognition across WorkWave customers enabled a shared microservice design
  • Webhook architecture closed the delivery loop automatically for app-based drivers
  • Scoped API keys solved multi-tenant isolation across environments
  • Documentation enabled independent deployment by implementation engineers
  • Manual fallback kept the solution viable for programs with elderly volunteers

❌ What Didn't Go Well

  • Vendor evaluation was reactive — built what customers suggested, discovered better options later
  • Two WorkWave customers got different solutions from separate impl teams — inconsistency complicated support
  • Volunteer drivers who wouldn't use the app created a persistent UX gap requiring manual fallback

The WorkWave lesson: A tool can be excellent for dispatchers but fail if drivers won't use it. The best route optimization in the world doesn't matter if the driver is on paper and no one knows whether the meal was delivered until they return. Onfleet succeeded because it treated the driver as a first-class user, not an afterthought.

06 — Results

What We Achieved

3
Customers in progress on the
productized Onfleet integration
Dramatically
Reduced manual effort
for planners & coordinators
New
Recipient features: delivery ETAs,
driver communication, fewer misses

Outcomes

07 — Retrospective

What I'd Do Differently

1. Structured Vendor Evaluation Before Shipping

Instead of building what customers suggested and discovering better options later, I'd invest in a structured vendor evaluation early — scoring on API quality, webhook support, driver UX, onboarding friction, and pricing. The path from Samsara to WorkWave to Onfleet was educational but not efficient.

2. Design for Non-tech Users from Day One

The volunteer driver gap was foreseeable given the population. I'd invest earlier in the manual fallback UX and think harder about whether paper and digital could coexist more gracefully.

3. Standardize Across Impl Teams Earlier

The two WorkWave customers getting different solutions from separate teams created inconsistency. Establishing shared patterns and documentation earlier would have prevented this divergence and made the Onfleet transition smoother.

4. Plan Multi-environment Architecture Upfront

The dev/sandbox vs. production environment setup for API key management and webhook routing took more time and attention than anticipated. I'd design that architecture upfront rather than retrofitting it after realizing we needed safe iteration and debugging paths that wouldn't disrupt active delivery operations.