top of page

Unifying maintenance and warehouse fulfillment workflows

My role

Sole Product Designer

(Research, IA, prototyping, design system, QA)

OperationMockup.png
Timeline
July - August 2026 (8 weeks)
My team

4 client stakeholders, 1 solution architect,
3 back-end engineers, 1 front-end engineer

"That's part of the reason what sent us down this path — that disconnect between the warehouse and the maintenance ticket."

-- Ryan · Director of Information Technology

01

CONTEXT

40% of repairs wait on a part that lives in another system.

Club Car Wash ran two systems side by side. Store managers reported maintenance requests in FMX. The warehouse managed order fulfillment in FlowTrac. Nothing connected the two.

So from requesting a part to chasing its status, a store manager or technician had to email or call the warehouse before any work could start. The warehouse paid for it too — answering the same questions by phone all day, with no way to point anyone at a status they could see for themselves.

05

SOLUTION

One shared record, one status chain

The same record connects the technician who needs a part and the warehouse that fulfils it. Each role then sees only the part of it that matters to them: the technician requests, the store manager tracks the order, the warehouse traces which job it came from.

Step 01 · Technician (Mobile)

Request the part from the job

Technician orders parts when reviewing the request, the parts readiness controls the work request: Awaiting for parts or Ready to work.

Step 02 · Tablet · Warehouse

Pick from a queue to fulfill

Only orders that can actually be filled allow users to start picking orders. Users can transfer the order to another warehouse with sufficient stock to avoid delaying fulfillment.

Step 03 · Technician (Mobile)

Resolve the job with what was actually used

Parts used and hours worked are captured in the same step that closes the job, rather than in a form afterwards. This ensures the stock system reflects the actual consumption.

Step 04 · Operation Team (Desktop)

Only the actions that apply, for the people allowed to take them

Everyone works from the same record, but the buttons change. Request parts, Resolve, Close, and Re-open appear only once a job has reached that stage, and only for someone permitted to do it. 

Reflection

Software like this fails quietly. The system and logic are what connect the work, so the internal alignment becomes more critical than ever. 

01. The loudest problem is rarely the real one
What a team asks for is usually a symptom. Here it was "show me the parts I need when I submit the work order" — but nobody was recording which equipment had broken, so there was nothing to pull from. I look for what's breaking in the workflow before touching the interface. Design moves faster when the direction is right.

02. Ship the system, not a screen
A screen solves one problem; a system solves the ones you haven't seen yet. On a timeline this tight, I was never going to keep up on my own. So I defined components, patterns, and documented rules that enable engineers to build screens I never drew and still get them right.

03. AI speeds up the work, not the thinking.
I use AI to move faster, but speed isn't the hard part. The rules, the reasoning, and the documentation behind the output are what keep the work coherent when someone else picks it up six months later.

View other works

Pulse_thumbnail.png

Streamlining recruitment workflow to drive strategic growth

Streamlining recruitment workflow to drive strategic growth

Thumbnail_Santanderapp.png

Optimizing the paperless setting flow to increase the adoption rate

Optimizing the paperless setting flow to increase the adoption rate

bottom of page