Iravika NerurkarLeadership review 2026

Areas of practice · 2026

The agreements that make the next customer answer possible

01

Distinguishing counted stock from a promiseable item

I examine the steps between an inventory observation and a promise a customer can act on. A returned item may exist in a store but still await inspection; another may be visible in a count while already reserved through a different channel. Those are operating states, not merely interface delays. In our 600-order rehearsal, ninety-six apparent availability errors exposed both conditions. I worked with store and supply owners to define the status and reservation handover before the system issued a firm collection message. The technical function could implement that agreement, but it could not decide an item's sellable condition or a commercial allocation policy alone. I can help a retailer identify the authority and evidence required at each transition, so that an integrated view does not make an incomplete stock record look like a customer commitment already secured.

02

Keeping service possible when a record link is incomplete

A return enquiry should not become an argument between applications in front of the customer. I help teams distinguish the technical lookup problem from the service decision and provide a route for both. In a 1,200-case review, 300 lacked the order link needed by the proposed process. We reconciled 200 and retained an explicit manual route for the remaining hundred. That did not determine whether every return should be accepted; retail policy and authorised colleagues still governed the decision. My responsibility was to make the available record and the unresolved condition clear enough that the next person could act. This practice includes support ownership after introduction, because a workaround that depends on knowing a particular engineer is not a durable service arrangement across a large store network.

03

Measuring the application without overstating the customer result

Retail technology has several clocks. The application responds in seconds, while a customer may wait minutes for a sequence involving people, stock and service choices. I want investment reviews to distinguish those measures. In a thirty-store study, item lookup improved from eleven to four seconds at the 95th percentile, while observed queue medians moved from 4.8 to 4.4 minutes in separate cohorts. The second measure did not establish the application as its sole cause. I could still support the change as a useful improvement without converting it into a staffing claim. My expertise is in connecting technical observation to the operating use it can support, identifying the remaining bottlenecks and preserving the sampling conditions when a result is shortened for an executive report or a wider rollout proposal.

04

Linking customer records without inventing permission

A common customer view can improve service when its links are dependable and its uses are properly authorised. Similarity between records is not enough to settle either question. In a 120,000-link exercise, 12,000 candidates remained ambiguous; further review confirmed 4,000 and left 8,000 separate. I supported preserving that uncertainty instead of treating a high merge rate as the main measure of success. The linkage decision also did not establish permission for a new use of the details. Relevant owners needed to examine that separately through the company's process. I can help a retail enterprise distinguish identity evidence, service purpose and use authority in its technology design, while avoiding an unsupported legal-compliance claim or the assumption that every matching contact detail represents the same person in every context.

How I lead

The customer should not have to understand our system boundaries to receive a clear answer.

At scale

The responsibility, in figures

162

Technology employees

Five direct reports; forty-five contractors separately

₹96 crore

Technology authority

FY2026–27: ₹62 crore operations and ₹34 crore change

34 years

Retail systems experience

Store applications, channel integration and enterprise leadership

In practice

Decisions and their consequences

Case 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.

Case 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.

Case 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.

Case 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.

Case 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.