Website pickup: where stock reservation breaks
The most common complaint about website pickup sounds the same: the product page shows "in stock at store," the customer places a pickup order, arrives — and the item is not there.
The cause is almost always the same: stock reservation lives on the website side, while the actual movement of goods is in the location's accounting system. There is no feedback between them, and the data diverges within a single shift.
Warehouse and website desynchronization accumulates over small things: sold at the POS, written off as defective, transferred between locations, received a delivery with a discrepancy — while the exchange runs on a schedule, once an hour or less often.
Until it completes, the storefront sells something that physically isn't there. The reverse situation is no better: the item is on the shelf but marked unavailable — the location loses a sale it had almost made.
Then manual work kicks in. An employee calls customers, a manager moves orders, someone edits stock by hand — instead of fulfilling orders.
Current stock availability turns into an agreement between people rather than a property of the system, and it holds only until the next shift.
The cost of such a breakdown is double-selling a single unit, cancellations at pickup, and customers who no longer trust the "in stock" label.
We break down how this is closed: where stock reservation should sit, how to connect the website to an accounting system such as 1C, and what to show the customer while the data is still in transit.
What changes after launch: pickup times, cancellations, workload
The first noticeable shift is order pickup time at the location. While the status is clarified manually, the operator spends several minutes searching and reconciling, and during peak hours this turns into a queue.
When readiness comes from the accounting system as a separate event, the warehouse worker sees the list of assembled orders and issues by code — the median drops to tens of seconds, and peak hours stop requiring an extra shift.
The second metric is the share of canceled orders. The cause is usually not logistics but that stock is confirmed after checkout, when the item has already been taken.
Atomic reservation at a specific location's warehouse and a reservation lifetime for assembly move the refusal to the moment of checkout: the customer immediately sees the item is unavailable and chooses another location instead of waiting for a call.
The most expensive class of reservation failures — "accepted, then canceled" — goes away first.
The third effect is the load on the call center and location staff.
A significant portion of inquiries are questions like "is the order assembled?" and "when can I pick it up?"; after launch, a notification with the pickup window is sent automatically on status change, and the location stops acting as a dispatcher.
Order readiness for pickup becomes a separate controllable state: if the exchange with the accounting system is delayed, a repeat synchronization delivers the status, and the discrepancy goes into a report rather than into a conversation with the customer.
All four slices — pickup time, share of cancellations due to missing stock, number of inquiries per order, and share of orders that reached readiness without manual intervention — are extracted from the log and compared with the pre-launch period. They show at which step the scenario is still losing orders.
Website pickup formats: reservation, prepayment, parcel lockers
The pickup scheme is determined not by the storefront but by what happens to stock at the moment of checkout. A soft reservation reduces the available quantity in the warehouse but does not write off the item, while a prepaid order locks the item to the customer until pickup.
This yields two parameters that define the behavior of the entire form: reservation lifetime and the rule for returning stock if the customer does not show up.
On one website, options usually coexist: part of the catalog runs on reservation without payment, part only on prepayment. The choice is dictated by where the item physically sits, who confirms pickup, and how quickly the accounting system returns current stock.
| Option | When it fits | Limitations |
|---|---|---|
| Reservation without payment | Item is on the sales floor or in the store warehouse, low item price | Need a strict reservation hold period (hours to a day) and timer-based auto-release, otherwise stock "hangs" and diverges from actual |
| Prepaid order | Expensive and rare items, goods ordered from a supplier | Refund on non-pickup, linking payment to the order, repeat payment after the period expires |
| Payment at the pickup point | An already operating location with staff and a POS | No automatic write-off: manual revenue reconciliation, higher risk of non-pickup, status closed manually |
| Parcel lockers | Dense flow of similar orders, pickup without staff | Cell dimensions, storage periods on the operator side, status exchange when a specific parcel locker is unavailable |
The hardest part here is not the table but the transitions between statuses.
If the pickup point is closed, the cell is occupied, or payment failed, the order must go to delivery or to a new reservation without losing the payment already made — otherwise support handles every such case manually.
Below we break down how this is closed at the level of integration with the accounting system and the location map.
Implementation stages: from reservation scheme to handover
The work follows an engineering order: first we record how pickup is arranged now, then design reservation for the real order flow, and only after that touch the exchange and test everything on live orders. This order removes the main risk — "we launched, and reservations are double-booking."
- Audit of pickup processes. We visit locations, look at who writes off stock and how, where double booking already occurs, which order statuses live in the accounting system and which live on the website.
- Design of the reservation scheme. We decide what exactly to reserve: an item unit at a specific location, a time slot, or an assembly window. We set the reservation lifetime and rules for releasing it on non-payment or expiration.
- Setup of data exchange. Stock, prices, and location statuses move between the website and 1C; we make the transfer idempotent so that resending an order does not create a second reservation, while regular reconciliation catches discrepancies.
- Scenario check on the map. We run through location selection with multiple addresses, incomplete data, and limited opening hours — the customer should not hit an empty list.
- Acceptance checks on real orders. We place orders on test and production accounts, verify stock after each step, deliberately break the exchange, and see whether it recovers on its own.
- Handover of policies. We provide a description of the reservation scheme, instructions for location operators, the procedure for resolving discrepancies, and a list of checks for a repeat run before releases.
What the customer receives: schemes, rules, instructions
After launch, you retain not only a working pickup scenario but also a set of documents by which it can be operated, enhanced, and handed over to another team.
We assemble it throughout the project: each artifact describes what is actually implemented, not a general scheme of "how it usually is."
- Data flow diagram — the order path from cart to reservation and back-writing about pickup: which services exchange data, what happens when the warehouse is unavailable, where unprocessed events accumulate.
- Exchange documentation — field composition, formats, frequency, item matching rules, and behavior when stock diverges; a test environment for verification is described separately.
- Order pickup policy — step by step: readiness confirmation, recording the fact of pickup, actions for an incomplete set and after the hold period expires.
- Instructions for location staff — scenarios with workstation screens: accepting an order, moving the interval, cancellation, disputed situation. Without technical terms.
- Access rules for sections — roles: who sees customer data, who changes intervals and limits, who only views reports, which actions go into the log.
- Location map and interval grid — how to edit them, what happens to already placed orders when they change, who is responsible for keeping them current.
- Operation manual — where to view exchange statuses, how to restart synchronization, how to disable the module without affecting regular order placement.
- Acceptance checklist — a set of scenarios by which you verify the system yourself before going live.
Such a set removes the main maintenance risk: when six months later you need to change intervals or add a location, you do not have to reconstruct the logic from the code.
Case study: a store chain cut pickup time by a factor of three
Before implementation, pickup in the store chain ran on a manual scheme: an order from the form was sent by email to a specific store, availability was checked by an administrator in the accounting system, and stock was updated by a daily export.
At pickup this resulted in 12–14 minutes — while they find the order, recount the items, and agree on a substitution. Around 9% of orders were canceled with the wording "out of stock," although the item was physically on the sales floor or in another store in the chain.
We built online reservation: at checkout, the item is blocked in the warehouse of a specific store, not "in the chain as a whole." The exchange with 1C was moved to short intervals instead of a daily export, so the store map shows current availability and estimated assembly time.
We added an order status model with notifications at each transition and a pickup workstation screen with search by code — the administrator does not search for the order in email but sees it in the queue.
Two months after launch:
- pickup time — from 12–14 to 4–5 minutes per order;
- share of cancellations due to "out of stock" — from 9% to 1.5%;
- support inquiries about order status — down 40%, the main scenario "is my order ready?" is covered by notifications;
- about three hours were freed up on the administrator's shift, which previously went to calls and reconciliation.
The key was not the interface but blocking stock at the checkout stage: it removes the very possibility of selling the same item twice and takes the role of arbiter away from staff.
Staff workload leveled out across days — the peak no longer depended on how many orders arrived by email.
What is the difference between a warehouse reservation and a reservation at the pickup point?
A warehouse reservation is a logical block on stock in the accounting system: the item physically lies on the shelf, but it is already subtracted from the quantity available for sale.
In 1C this is a register entry, and it can be released with one operation — the unit instantly returns to sale. No goods movement occurs.
A reservation at the pickup point is a different entity. A picking task is created for it, the warehouse worker removes the unit from the shelf and records a transfer of goods between the warehouse and the pickup zone.
The storage location changes, the item leaves the main stock, and this cannot be canceled with one operation: reverse acceptance is needed, and if the location is in another city, reverse transportation as well.
Hence the different reservation lifetimes and cost of error. A warehouse reservation lives for hours and is extended by a scheduled task: the customer did not come — the block is released, and the item returns to sale automatically.
A transfer is tied to the picking schedule and physical availability at the location: an overdue order is a physically set-aside unit that no other customer can see.
Order priority is also resolved differently. When two orders claim the last unit, with a warehouse reservation the queue is by checkout time; with a transfer, the queue is by picking fact.
If the rule is not set explicitly, both customers receive confirmation for the same item, and one of them leaves empty-handed.
Common technical doubts before launch
Before launching pickup, the questions are usually the same: what to show if stock changed a minute ago, how to do without an accounting system, and what to do with an unclaimed order. Below is how this is arranged on the website side and where the boundary of responsibility lies.
How current is stock?
The quantity decreases at the moment of order confirmation, atomically — two customers will not take the last unit. Between exports, stock may become outdated, so we do not show a location with zero on the map, and we hold the reservation until pickup.
Can we do without an accounting system?
Yes, if there are few locations and items do not overlap: we keep stock in the application itself, edit it manually or by a daily export. With several locations and sales on the sales floor, double accounting appears — synchronization becomes mandatory.
What if the reservation period expires?
The period is set per pickup point — an hour, a day, three days. After expiration, the order is canceled automatically, the quantity returns to sale, and the customer receives a notification: the sales floor does not fill up with unpaid orders.
Who is responsible for write-off?
Write-off is recorded at the moment of pickup, not on the website: pickup is closed by the point's employee using the order code. If there is no integration with accounting, the source of truth is the warehouse, and discrepancies are resolved using the operations log.
Let's discuss the task: what to send for an estimate and plan
To come back with an estimate and work plan, rather than general words, we need input on several points. The more accurately the current pickup process and the set of locations are described, the fewer assumptions we build into timelines and scope.
- Composition of pickup points. How many warehouses, stores, or parcel lockers are involved, whether each location has its own schedule, daily order limit, and service area.
- Current pickup process. How the order reaches the location today: a printed list, a phone call, or exchange with the accounting system; who confirms readiness and what happens to an unclaimed order.
- Accounting system and access. Where stock and orders are maintained, which exchange interfaces exist, whether there is a test environment, and who on your side approves the integration scheme.
- Reservation rules. How long we hold the item, at what moment the reservation is released, how we handle a partially available order and different assembly times by category.
- Map and location selection. By what attribute the customer chooses a location — address, district, landmark — and whether filtering by availability of a specific item in the warehouse is needed.
- Customer notifications. Through which channel we notify about readiness and whether the waiting interval should be limited or a repeat reminder sent.
- Constraints. Seasonal peaks, load requirements for website pickup, personal data handling rules.
Describe the task in free form, attach the list of locations and examples of invoices — this is enough to discuss the task concretely.
We will come back with an estimate and work plan: stages, the order of connecting locations, the exchange scheme with the accounting system, and a breakdown by phases.
