Solving the right problem to make operations 70% faster

How I Found the Real Problem

The brief came to me in October 2024. The CE team with ten agents, was handling food replacement orders every week across all of Hangry’s brands, outlets, and sales channels. Every complaint that qualified for a replacement had to be handled individually.

I talked and discussed with Regina, the CE team leader. What surprised me most wasn’t the volume. It was the time. One replacement order done through the Hangry App took up to ten minutes. This is a pain point for Regina’s team.

TIME PER REPLACEMENT ORDER

Around 10 min/order

Using the Hangry App, a consumer product never built for this workflow

REPLACEMENTS PER WEEK

150-200 orders/week

Hangry runs multiple brands across multiple outlets and platforms.

Using the Hangry App for this workflow wasn’t just slow, it was the wrong tool for the job. The more I understood how Hangry’s business actually worked, the clearer that became.

Four structural problems, all rooted in the same thing:

PROBLEM 1

Menu Coverage Gap

Hangry App only shows menus sold directly to customers. Items exclusive to Grab, Gojek, Shopee, don’t exist there. When menu wasn’t available, CE reached out to the outlet directly, disrupting kitchen operations in the process.

PROBLEM 2

Sub-brand Gap

Hangry’s sub-brand only exist on third-party platforms. Some sub-brand items appear under the main brand in the Hangry App, but many don’t. Same workaround. Reach out to the outlet directly, same disruption.

PROBLEM 3

Pricing Gap

Hangry App shows consumer-facing prices. Every replacement placed through it was charged at full retail. No way to use internal pricing or COGS. Every replacement cost more than it should have.

PROBLEM 4

No Centralization

Each CE agent used their own Hangry App account. There was no shared view. No way to track orders, monitor volume, or control costs across the team. Regina had no visibility into what her team was doing.

How I Solved It

The PM’s brief came with a proposed direction: a form that CE fills to place a replacement order, with part of it shared to the customer to input their delivery address and location. A stakeholder also suggested extending this into a WhatsApp chatbot.

I mapped out both flows before we sat down together (me, the PM, and the engineers). Not to commit to either direction, but to have something concrete to pressure-test.

Customer Reach out via WA

WA chatbot Comms & form

Form shared to customer Fill address + pin point location

Approve or reject? CE decides

CE review Check form in dashboard

Notify customer Explain reason

Create replacement order Order pushed to outlet POS

Reject Approve

Option 1 — WA chatbot + Internal Ops Dashboard + Share Form

Customer Reach out via WA

CE agent Comms & form

Form shared to customer Fill address + pin point location

Approve or reject? CE decides

CE review Check form in dashboard

Notify customer Explain reason

Create replacement order Order pushed to outlet POS

Reject Approve

Option 2 — Internal Ops Dashboard + Share Form

Then we ran them against four constraints we had: did it solve the CE problem? Did it reduce our replacement order cost? Was it low effort for our customers? Was it low effort for our engineers?

Idea	CE problem solved	Cost reduced	Low user effort	Low tech effort
Option 1	Yes	Yes	No	No
Option 2	Yes	Yes	No	Yes

Both option failed on the same constraint — user effort. In both case, the customer still had to fill part of the form and pin point their own location.

These are customers who just had a bad experience. Asking them to do anything extra, adds friction to a moment where trust is already thin. We almost pushed through anyway, with CE compensating by handling as much as possible, but something stopped me.

I remembered building the location flow for the Hangry App. The pin point feature we used there was powered by a paid mapping service. A fifth constraint had just appeared, it will added another business cost if we continue with these plan.

That’s when the Google Maps link idea came up to my mind.. Share links already contain latitude and longitude data. CE could simply ask the customer to share their Google Maps location. No form to fill, no pin point to drag, no paid service. After we checked it together, it worked and it was free. This will removed all the burden from above.

Open form Internal Ops Dashboard

Paste maps link address auto populate

Select menu All channels & brand, internal price

Order pushed to POS Centralized, trackable

Submit for approval Regina reviews

Handled entirely by CE, no customer input required

Here’s what that translated to in practice, the replacement order from inside Internal Ops Dashboard that CE uses to place orders, and the scheduled order tab added to the POS so outlets can process them.

UI screens have been reskinned for confidentially. Structure and functionality reflect the actual product.

Replacement order list in the Internal Ops Dashboard — Internal Ops Dashboard

Replacement order form, address pasted from a Google Maps link — Internal Ops Dashboard

Scheduled order tab in the outlet POS — POS

Replacement order opened at the outlet POS — POS

The Impact

The module shipped in February 2025. A few weeks after it, I checked back in with Regina.

The tools was stable, almost no issues after we clearing up the early bugs. Regina said: the centralization meant she could actually see what was happening across the team, something that simply wasn’t possible before.

But the number that stuck with me was the time.

BEFORE

Around 10 min

Per replacement order via Hangry App

AFTER

Around 2-3 min

Per replacement order via Replacement Order Module

REPLACEMENT ORDER WORKLOAD

70% Faster than before

Based on Regina’s interviewed

For the cost side was harder to quantify precisely, but the structural shift was clear, replacement orders were no longer being placed at customer-facing prices. Internal pricing through Internal Ops Dashboard meant every cost less than from the Hangry App.