Dispatch Details: When the App Couldn't Answer "What Did I Get Paid?”

Context & the problem

During peak harvest season, SJs sent 2–3 trucks a week carrying 30–32 metric tons of corn, handling millions of IDR, yet the most critical information about those dispatches never reached them through the app. Unloading locations, quantities, feedmill feedback, split-delivery decisions: all of it lived in WhatsApp. When a truck was unloaded across multiple feedmills, each with different prices and quantities, the final payout became a number users had no way to trace or verify. When trucks were rejected or rerouted, the reasons were equally invisible, forcing every question through a 4-person chain: SJ → AC → MC → PA/Data team. Each resolution took 10–15 minutes. In South Sulawesi, one person's entire day was consumed by it. In our largest province, 30% of trucks had multiple GRNs, every third truck triggering that chain.

WhatsApp wasn't a side channel here; it was the actual support system. Once an SJ's question got answered there, the loop closed instantly: no ticket, no CX call, no record it ever happened. That's a real function, but an invisible, unscalable one, entirely dependent on whichever AC or MC happened to be reachable that day. It also meant our formal support metrics were structurally blind to the real size of the problem. Low CX call volume was never a sign the system worked, it was a sign the actual problem-solving had already migrated to a channel with no analytics attached.

The underlying business context: buyer-selection models (DPM and FSM) had recently gone live across all regions. Both essentially let an SJ pick a buyer before sending a truck, differing only in how volume and price were governed: DPM on fixed contract terms, FSM on spot market pricing. Managing rejections and redirections had become a compounding pain point because price calculations were tightly coupled to quotas and feedmill selections, meaning any rejection, reroute, or multi-feedmill unload required manual adjustment by the PA/Data team.

The app wasn't failing at presentation. It was failing to be the source of truth for decisions that directly affected what users got paid.

What success looked like

For internal teams: Reduce and eventually eliminate manual intervention, remove the dependency on Google Sheets for adjustments, decrease settlement time per dispatch, which fed directly into Jiva's most critical metric, cash rotation.

For SJs: Show them what was happening to their trucks. Give them enough information to understand their payout without calling their AC or checking WhatsApp. Rebuild trust in Jiva as a service.

What research told us and the five decisions we made because of it

Across multiple regions, the same complaints surfaced independently: users couldn't explain their final payout, didn't know where their truck had gone, and had no way to verify deductions already hitting their accounts. 17 SJs in Jeneponto alone flagged the same label, "Penyesuaian Uang Muka", as incomprehensible. 7 SJs in Gowa and Jeneponto said silent deductions left them unable to pay farmers, pushing them toward leaving Jiva entirely. Every MC we spoke to said they couldn't understand what the progress bar states meant.

This wasn't a layout problem. Users weren't confused by how information was arranged, they were missing the information entirely, or the information that existed wasn't theirs to begin with.

Decision 1 — Replace the progress bar with a plain-language timeline One MC asked directly: "What does the green and check mean? Does it mean it gets unloaded 3 times, and the last point means it's not finished yet?" We replaced the visual metaphor with a timestamped event log: truck sent, truck arrived at feedmill, truck accepted. No interpretation required.

Decision 2 — Lead with the financial outcome The question users had after sending a truck was: how much did I earn or lose? The old screen made you scroll past driver contact details and farmer harvest weights to find it. We put the settlement amount at the top.

Decision 3 — Remove what wasn't ours to show Driver contact details and individual farmer harvest weights ate nearly a full viewport. SJs hire their own drivers, they already have that number. Farmer weights served internal ops, not the SJ checking their payout. We removed both.

Decision 4 — Build the "Received by Jiva" breakdown For trucks split across multiple feedmills, the old screen showed nothing, reasons, quantities, and prices from each stop existed only on WhatsApp. We made backend changes so internal teams could input this data directly, then surfaced it per feedmill: unloaded weight, moisture level, refracted price, rejection reason. For the first time, a user could see exactly why their payout was what it was, without calling their AC.

Decision 5 — Fix the languag

"Penyesuaian Uang Muka" became "Pemotongan Quality Discount." 17 users flagged the same term across the same region; it had no design justification to begin with.

One principle held across all decisions: Only show what's needed. Everything else goes somewhere else, or goes away entirely.

Before and Now

Leading the team

My goal was making sure everyone understood why we were doing what we were doing, not just what needed to be done. With Fathia, that meant spending extra time upfront so her research questions weren't just technically correct but connected to the actual decisions we needed to make. With Pam, it meant holding space for doubt openly rather than projecting false certainty, the design was complex enough that pretending otherwise would have slowed us down.

"You always made sure you provided me with enough context so that I understand why we should conduct the research." — Fathia Ramadina, , Design Researcher

"Your sincere efforts at knowing more about the SJs — it's really motivating and empowering." — Atisha Kudesia, Product Designer

"Your confidence is the thing that makes me feel safe." — Prasetyo Pambudi, Product Designer

Outcomes of the project:

• WhatsApp volume dropped and that's a bigger deal than a simple down-tick. WhatsApp had been functioning as an entire unofficial support system: every query resolved there was one that never generated a ticket, a call, or a record. Retiring that dependency meant moving real, previously invisible resolution work into a channel we could actually see and track. We don't have an exact count on the drop itself, but the signal was consistent across regions — and for the first time, that work was happening somewhere measurable.
• ACs got their time back. Activation Coordinators were the first line of response for every dispatch confusion, a role increasingly consumed by questions the app should have answered. With the new screen live, ACs returned to supporting SJs on procurement decisions instead of explaining payout math.
• Users trusted the numbers. In follow-up research, MCs found the multi-GRN breakdown significantly more useful than what existed before. One MC in Central Java said: "This is simpler for partially accepted cases, we don't need to create/book a new code."
• What we couldn't fully measure. Settlement time and cash rotation impact were key metrics for Jiva but difficult to isolate to this change alone. The South Sulawesi workload reduction was reported directionally, not tracked formally. If we did this again, we'd instrument these before shipping, not after.

What I learned while leading this project?

• Stakeholder alignment was the actual design problem. This project touched product, data, internal ops, and engineering simultaneously. The screen couldn't change without the backend changing; the backend couldn't change without the PA team changing how they input data. None of it moves without people agreeing it's worth doing. What worked: communicating progress consistently, making the problem visible to everyone who needed to care about it, and treating the service map, the full MC → AC → PA → Dev chain and its cost, as more persuasive than any screen design.
• I'd instrument before we ship, not after. The outcomes were real but hard to prove. Cash rotation was Jiva's most critical metric and we didn't set up a way to measure our contribution to it. For a project with this much business stake, measurement should be designed alongside the solution, not bolted on after.
• What I wouldn't change. Prioritising wireframes over high-fidelity early, it forced the team to debate structure and hierarchy without getting distracted by polish. And bringing the research team in at the start rather than handing them a brief: Fathia's work was stronger because she understood the why behind every question, not just the questions themselves.

Some behind the scenes