An order-status page looks simple when you describe it as a screen. A customer enters the relevant information and sees where an order stands. The more useful design question is how that status is created and maintained.
At OVZA, a request for company-formation tracking became a system with customer-facing status visibility, controls for operations staff and automatic transitions based on predefined logic. I developed the functionality behind those parts of the workflow.
Start with the meaning of each stage
A status label needs a meaning that the people using the system can understand. A customer wants to know where the work stands. Operations needs to know what has happened and what can happen next. Those views are related, but they may require different detail.
For a new project, I would begin by asking what each stage means and which event should move an order out of it. The answer helps define both the interface and the behavior behind it.
Decide who changes the status
The OVZA system allowed operations staff to move an order between stages. Some transitions were automatic. That distinction needs to be explicit in a tracking design.
A manual transition needs a clear operational action. An automatic transition needs a rule and an event that the system can recognize.
When discussing a new requirement, I would also ask what should happen if the expected event does not arrive, if a transition is wrong, or if someone needs to correct it. Those are questions to investigate before treating the workflow as complete.
Connect the customer view to operational reality
The tracking page becomes useful when the information shown to the customer reflects the work being managed behind it. Discussing the customer view and operational controls together makes that relationship easier to understand.
In the OVZA work, my contribution was to develop that connection. Customers could see the current company-formation stage, and operations could manage its progression.
The capability is clear. Measuring its effect on support volume or customer satisfaction would be a separate step, with an agreed baseline and time period.
Questions for the next tracking feature
- What does each stage mean to the customer and to operations?
- Which actions or events change it?
- Which transitions are manual and which are automatic?
- What should happen when information is missing or a change needs correction?
- What result will we measure after release?
That last question is one I want to make more explicit in future work. Building a capability gives us something to use. Defining a success measure helps us assess whether it is helping in the way we intended.
Follow the workflow beyond the screen.
This article draws on my work as a Senior Web Developer at Andersen in Egypt. Read the OVZA case study for the project context and my contribution.
Frequently asked questions
What should an order-status page show?
Show a meaningful current stage that reflects operational work, with a clear next step when the customer needs to act.
Does a tracking page prove that support requests decreased?
No. That outcome needs a baseline and measurements after release. The case study describes the capability built, without claiming an unmeasured reduction.