A customer taps a button on a phone screen, drives to a store twenty minutes later, shows an ID, and walks out with a new device. From the outside, buy-online-pick-up-in-store looks like a toggle. Ship it, or don't. Choose the store closest to you.
Venkata Lakshmi Sowjanya Gajjala has spent years building the part nobody sees.
Sowjanya is a Principal Engineer at a major U.S. wireless carrier's mobile commerce platform, one of the architects responsible for the backend workflow that governs a pickup order from the moment it's placed to the moment a device leaves the store. The platform she works on serves more than 10 million wireless lines. Every pickup transaction across the carrier's retail footprint runs through the orchestration she helped design.
"Buy online, pick up in store is mostly a UI feature. From a customer's side, it looks like a toggle," Sowjanya says. “In practice, it's one of the more operationally demanding fulfillment paths to get right, because it depends on a physical store, a real person packing a real item, and a customer showing up, or not.”
That last clause carries most of the engineering weight.
Consider what has to happen between the tap and the handover. An order enters the system and has to be routed to a specific store's inventory. A store associate has to be told, in real time, that something needs packing. The system has to know when the packing is done. When the customer arrives, their identity has to be verified. Payment has to be captured at that exact moment. Billing and provisioning have to fire immediately after, so the device is ready to activate before the customer gets back to the car. None of these systems, historically, were built to talk to each other.
Sowjanya joined the platform before it launched, as a technical lead, and grew through engineering management into the most senior individual-contributor role in the organization. She stayed close to the architecture on purpose. Her ownership on the pickup flow spans three intertwined pieces: the order-to-pickup orchestration itself, the APIs that expose live order status to store-facing tooling, and the identity and payment steps at handover.
The store side is where the assumptions break.
Most fulfillment architecture is built as if every system will report status cleanly and on time. A warehouse conveyor belt does. A store does not. An associate might get pulled onto the sales floor mid-pack. A tablet might lose signal for a minute. A "packed" event might fire, or might silently fail to. If the backend trusts that single signal, an order can sit in limbo indefinitely, and nobody notices until a customer walks in expecting a device that the system doesn't think is ready.
Sowjanya's answer was a layered confirmation approach. The workflow listens for the real-time packed event from the store system, but it also runs a periodic check that independently verifies pack status if the event doesn't arrive within an expected window. Either path converges to the same next step. The order moves forward whether the primary signal made it through or not.
"The system needed to be resilient to imperfect real-world usage, not just clean, well-behaved API calls," Sowjanya says.
Then there is the customer who never shows up.
Reserved inventory that sits on a shelf indefinitely is a real cost. A device tied to an order that will never be completed is a device that can't be sold to the next customer. Designing for the shopper who follows the expected path is straightforward. Designing for the absence of an action, the pickup that just doesn't happen, is a different exercise. Sowjanya led the design of a time-based reminder and cancellation flow that runs parallel to the main pickup process, sending reminders on a schedule and, if the pickup window lapses, automatically cancelling the order and releasing the reserved inventory back to the store.
The point of automating all of this, she says, was never really about the software. It was about what the software freed the humans to stop doing. Before, store staff and operations teams spent a nontrivial share of the day chasing order status across systems, making calls, checking screens against each other. The workflow absorbed that coordination cost so the associate could focus on the person standing at the counter.
Outside of work, Sowjanya has been writing publicly about what enterprise AI can borrow from telecom-scale fulfillment, publishing on Medium under her own name, and is drafting original technical research on order orchestration architecture she plans to submit for peer review.
Her core argument, whether she's talking about pickup workflows or the next wave of agentic systems, tends to land in the same place. The features that sound simplest to describe are usually the ones hiding the most operational complexity underneath. Physical, human-driven steps deserve the same architectural rigor as the digital ones.
"Don't underestimate a fulfillment option just because it sounds simple to describe," Sowjanya says. The toggle on the screen is the easy part.