From product questions to request lifecycles

A customer request can sound simple: “Is this in stock?”, “Can you order this?”, “When will it be back?”, or “Can someone check with the supplier?” On the surface, these are product questions. But in a retail and e-commerce operation with a large product catalogue and multiple moving parts, the real issue was rarely the question itself. It was what happened after someone asked it.

A request might be remembered by the person who received it. It might sit in a Drive file, get mentioned in a WhatsApp group, or depend on someone remembering to check back later. One supplier accepted orders through the POS, while another had to be emailed manually. Some products were ordered, but not clearly linked back to the customer who had originally asked for them.

So when an item came back in stock, the team did not always know who was waiting for it, who owned the follow-up, or whether the customer had already been contacted. Nobody was being careless. People were trying to help. The problem was that the request had no shared place to live.

The requirement was a symptom

This is why “give me clearer requirements” is usually the wrong place to start. A vague requirement often means the workflow underneath it is vague.

Everyone held a piece of the work. The customer knew what they had asked for. The person on the shop floor knew the conversation. The supplier knew what had been ordered. The manager might know the priority. The person handling product or e-commerce information might know what had changed in the catalogue. But those pieces did not always meet in one place, so the request stayed fuzzy.

The real question was not only what the customer wanted. It was where the request went after it was made, who owned the next action, how the team knew whether it was ordered, unavailable, back in stock or already handled, and what happened when the person who took the request was not in that day.

That is where the actual requirement started to appear.

The tracker was not the system

The useful shift was to stop treating these as one-off product questions and start treating them as a request lifecycle.

A tracker helped, but the tracker was not the system. A tracker is only useful when the team agrees what it is tracking and what should happen next. The real work was naming the states a request could move through: received, checked, supplier contacted, ordered, back in stock, customer updated and closed.

Without those states, a request was just another note. With them, it became work that could be owned, handed over and finished. Writing something down created a record. Designing the workflow created accountability.

The owner field mattered because retail service is not generic. The person who takes a request usually knows more than any system can fully capture: how the customer asked, whether it was urgent, whether they are a regular, and what kind of alternative might suit them. Good service is not just answering the question. It is making the customer feel remembered.

So the system could not take ownership away from the person closest to the customer. It had to support them by keeping the status visible and making the next step harder to lose. That was the difference between building a list and building an operating layer.

Workflow first, automation second

The first move was not to automate the process. It was to make the lifecycle visible.

Once the states were clearer, automation became useful in specific places. When an item came back into stock, the request record could connect that stock change back to the customer who had asked for it. That meant the team did not have to rely only on memory, scattered notes, or someone saying, “I think someone checked this.”

That sentence usually means the workflow is not visible enough.

The automation only worked because the workflow underneath it had become clearer. If you automate before that, you just move the confusion faster.

What I took from it

A clear requirement is usually downstream of a clear workflow. When the movement is visible (request, owner, supplier, status, follow-up), writing it down becomes easier because everyone is finally describing the same thing.

That experience changed how I think about requirements. I do not only ask, “What needs to be captured?” I also ask, “What decision or action should this information create?”

If a request does not create ownership, a status and a next step, it is not really a requirement yet. It is a note waiting to become work.

So before I ask anyone for better requirements, I ask a smaller question first: do we actually know how this work moves?

That is usually where the real backlog item is hiding.