Returns portal
One click processes a return in the ticketing system and the ERP. Handling time fell by 65 % to under five minutes.
Context
An e-commerce company selling fitness equipment through its own shops and large marketplaces across Europe. Every return touched the ticketing system, the ERP and the warehouse, and each step was done by hand in a different tool.
The job
- A customer portal where the buyer registers the return and sees its status.
- An employee portal where support processes the return with one click: ticket updated, ERP documents created, refund or replacement triggered.
- Operation, updates and further development after the launch, as the single owner.
Decisions
- Workflows in Windmill, not in the ERP
- The ERP and the ticketing system stay the systems of record. Windmill holds the process, calls both through their APIs and keeps every run visible. A change to the process is a script change, not a vendor ticket.
- One return equals one idempotent job
- Each click creates a job keyed by the return. A retry after a failed ERP call can never book the same return twice, and support can press the button again without fear.
- Humans keep the decision, the system does the typing
- Support decides refund or replacement; everything after that decision is automated. That split is why the process got faster without losing control over money.
- Status visible to the customer
- The customer portal reads the same state the employee portal writes, so “where is my return” tickets stopped being a separate workload.
Outcome
- Average handling time per return down 65 %, to under five minutes.
- Sources of error between ticketing, ERP and warehouse removed; one log per return.
- Co-developed, then fully owned: maintenance, updates and new features.
Stack: Windmill, TypeScript, REST APIs of the ERP and the ticketing system, PostgreSQL.