Priority outcome 01
Ninety-six items that existed in the records but could not be promised
A September 2024 collection-service rehearsal examined 600 proposed orders across a defined store cohort. The recorded stock supported 504 allocations as expected. Ninety-six apparent availability results were wrong for the intended promise: fifty-four items were returns awaiting inspection and forty-two were already reserved elsewhere. The problem was not simply that one application refreshed too slowly. The systems were using availability to describe different operating states, and a customer-facing message could conceal that difference.
I brought store operations, supply owners and the channel team together to define the transition from counted item to confirmed reservation. Retail colleagues retained responsibility for whether a returned item was fit for sale and for the allocation policy. My team changed how the agreed status moved through the applications. We accepted a four-week controlled stage rather than widen the service on the strength of an apparently complete inventory view. The defined work cost ₹3.6 crore, including the interfaces, status review and store preparation.
The channel launch lead favoured keeping the announced date and funding exception handling. The alternative was to continue offering a firm collection promise and resolve the exceptions through customer service. That would have transferred a known internal ambiguity to the shopper and the colleague at the counter. We instead withheld the firm message until the reservation was confirmed under the agreed rules. Where an item was still under inspection or already allocated, the system needed to supply a clear status rather than a misleading affirmative answer.
At the end of the controlled stage, all 600 examined proposals carried the correct status for their scenario, including the ninety-six exceptions. That was rehearsal evidence, not a count of actual orders successfully collected. We still needed operating observation during introduction and a route for new exceptions. I reported the cost and the limited cohort alongside the result. The change made the promise more intelligible because we agreed what it meant before asking an interface to transmit it faster.
I would ask store teams to supply examples of unpromisable stock before approving the availability interface, ensuring the first specification distinguishes a recorded item from a customer commitment.
Priority outcome 02
A return lookup with an explicit route for the unresolved hundred
In February 2025 we examined 1,200 return-lookup cases before extending a common service workflow. Nine hundred carried the order details the process expected. Three hundred did not have a dependable order link through the proposed route. Some records required reconciliation across earlier store and online systems. The absence of a link did not by itself establish that a customer lacked a valid service request, and it did not give the technology team authority to decide the return outcome.
I supported an eight-week programme costing ₹1.4 crore to address the lookup and handover. The implementation lead preferred to exclude the difficult records from the initial scope. We could have treated every unresolved record as an exception to be handled outside the new workflow, leaving stores to find their own contact. Instead, operations and technology agreed how the available evidence would be presented and where a case would go when the link remained incomplete. The retail policy owner retained the acceptance decision. My team took responsibility for the record route and the support arrangements that made it usable.
Reconciliation supplied dependable links for 200 of the 300 cases. The remaining hundred entered a defined manual review route with named ownership, rather than being merged, rejected or silently counted as resolved. We preserved what was known and what still needed examination. Store colleagues could then explain the next step without suggesting that an application error settled the customer's eligibility. We made no finding of fraud from the missing-link count and did not use the exercise to change customer policy.
The result was a complete disposition for the reviewed cohort, not a claim that all 1,200 returns had been accepted or that every future lookup would work. I kept the unresolved hundred in the report because they tested whether our service design remained useful when the technical repair was incomplete. A common workflow earned its place by giving those cases a dependable route as well as making the straightforward ones easier to process.
I would design the unresolved-return route before implementing the common lookup, so service colleagues can influence the exception process while the application is still being shaped.
Priority outcome 03
Seven seconds faster at the screen, twenty-four seconds different in the queue
A thirty-store study over six weeks in July and August 2025 examined an item-lookup application change. The 95th-percentile lookup response fell from eleven seconds to four seconds. At the same stores, observed customer queue medians moved from 4.8 minutes in the earlier cohort to 4.4 minutes in the later cohort. These were different measures from separate before-and-after observations. The application result was substantial, but it could not responsibly be described as a seven-second reduction in every customer's wait or as the sole cause of the queue change.
I supported the ₹2.8 crore deployment while asking the programme to retain both accounts. Store operations explained that waiting also depended on staffing, service questions, item retrieval and the mix of customer needs. A faster lookup could help colleagues without removing all those constraints. Our programme finance partner initially sought a staffing benefit to strengthen the proposal. The alternative presentation would have multiplied the technical improvement across transactions and converted it into an attractive staffing equivalent. We had neither the work study nor the operating decision needed to justify that claim.
We examined how colleagues used the improved response and where waiting remained. The programme retained the sample periods, store cohort and observation method with the results. We did not subtract a percentile of application response from a median of total queue time, because those are not paired measurements of the same event. Nor did we claim that the later cohort differed only because of the deployment. The descriptive comparison could guide further investigation without carrying a causal conclusion it had not established.
The immediate outcome was a faster lookup service in the measured cohort and a more honest account of the customer's waiting experience. Operations used the remaining observations to consider further service changes, while technology monitored the application. I regard this as a useful investment decision because we did not require a modest customer-level observation to resemble the larger technical result. The benefit could be worth pursuing within its actual scope, with the next question still open.
Next time I would agree the customer-queue observation alongside the screen-performance test, avoiding a later discussion in which two useful measures appear to describe the same benefit.
Priority outcome 04
Eight thousand customer links left unresolved rather than merged
A customer-record exercise in November 2025 evaluated 120,000 candidate links across store and direct online records. Under the agreed matching rules, 108,000 had sufficient consistent evidence for linkage. Twelve thousand remained ambiguous. Similar contact details could arise in different circumstances, and the programme could not resolve identity merely by preferring a high merge rate. We needed a record of why a link was accepted, as well as a way to preserve uncertainty where the evidence was insufficient.
I recommended a bounded review programme costing ₹95 lakh. The customer-marketing sponsor preferred a wider combined view for service planning. The alternative was to lower the matching requirement and let service teams correct mistaken combinations later. That would have made a more complete-looking customer view at the expense of confidence in what it represented. Relevant business owners and the specialist team agreed the review process. The technology function implemented it and retained the basis for each decision; we did not invent customer details to close the unresolved group.
Further examination confirmed 4,000 of the 12,000 ambiguous links. The remaining 8,000 stayed separate. That left 112,000 linked candidates and 8,000 unresolved candidates within the examined set. Those counts did not necessarily equal unique people, and I did not present them as a customer population or a marketing audience. The programme also distinguished identity linkage from permission to use the details for a particular purpose. A better match did not supply a new authority that had never been established through the company's process.
We completed the exercise with the unresolved group visible and a continuing owner for later evidence. I reported the cost and the limitations beside the increased linkage count. The result was a more explainable record, not a legal-compliance certification or a claim that every related entry had been identified. For me, the decision demonstrated a useful restraint: a common view becomes more credible when it shows where the enterprise does not yet know enough, rather than making every gap disappear through a convenient technical rule.
I would include ambiguous customer relationships in the initial linking exercise, rather than begin with straightforward matches that make the eventual exception population look peripheral.
Priority outcome 05
Examining 720 support cases before buying another tool
A proposal for a new store-support platform reached our investment review in April 2026 with an estimated ₹4.2 crore cost. Before recommending it, I asked the team to examine 720 recent support cases. Of these, 480 concerned permissions, 140 concerned catalogue information and 100 concerned hardware. The permission group was especially revealing: many cases waited for an authorised business owner to make or confirm a decision. A new ticket interface might make that waiting more visible without resolving its cause.
I recommended deferring the platform decision while we tested a narrower ownership and routing improvement costing ₹85 lakh. Operations colleagues identified the relevant decision owners, and my team made the handover and status clearer. The store-support manager favoured the new product because the existing interface made open work difficult to follow. The alternative was to proceed with procurement and expect the implementation to solve the responsibility questions along the way. That would have committed the larger expenditure before we understood whether the proposed product addressed the dominant difficulty in this cohort.
Over six weeks, 410 of the 480 permission cases were resolved through the revised route. Seventy still awaited the necessary authorised decision and remained open in the account. Catalogue and hardware cases continued through their separate processes; I did not claim that the programme had resolved all 720. We also did not treat an access request as something technology could approve merely because it had waited a long time. The owner still needed to decide, and the system needed to show that dependency honestly.
The initial ₹4.2 crore request had not been approved, so its deferral was not a realised cash saving to subtract from the ₹85 lakh work. It was an investment choice informed by a more useful explanation of the support demand. The platform proposal could return if a clearer requirement justified it. I wanted store colleagues to experience a dependable route to an answer, while making sure the enterprise did not mistake a new tool for agreement about who was responsible for giving that answer.
I would classify the support demand before inviting another platform proposal, bringing responsibility gaps into the requirements discussion while changing the tool is still only one possible response.