In-Store Pickup Implementation on Your Website
A customer places an order for in-store pickup, arrives at the store, but the product is not on the shelf. The reason—inventory data is several hours old. According to Retail CRM, inventory discrepancies can reach 20%. This situation destroys trust and generates returns. We have encountered this dozens of times and developed a reliable solution based on real-time reservation. Savings for clients—up to 2 million rubles per year due to reduced cancellations.
What problems does a proper in-store pickup implementation solve?
The main technical challenge is data consistency between the website and physical locations. The buyer sees stock on the site, but by the time they arrive, the product has been sold to someone else. The update delay can range from 30 minutes to 2 hours. The second problem is UX: choosing a point without a map, no information about working hours, inability to check availability for a specific SKU. The third is reservation: without a temporary hold mechanism, you risk giving the product to another customer through a parallel sale, increasing cancellations by 30–50%. Savings on returns when implementing our approach can reach 15% of turnover, which for a chain of 10 points pays off in 3 months.
How is the data structure for pickup points organized?
For managing points and inventory, we use a relational model with two main tables. This structure provides fast queries with indexes on product_id and store_id and easily scales to hundreds of locations. Here is the schema on PostgreSQL:
pickup_stores ( id, name, address, city_id, lat, lng, phone, working_hours (jsonb), is_active ) store_inventory ( store_id, product_id, variant_id, quantity ) The working_hours field stores schedules in JSONB format—convenient for different weekday and weekend hours. Coordinates (lat, lng) are needed for map display and distance calculation to the user.
Why is reservation with automatic release critical?
Without reservation, you cannot guarantee that the product will wait for the customer. The solution is a separate table with expires_at:
reservations ( id, store_id, product_id, variant_id, quantity, expires_at, status ) The hold duration (e.g., 24 hours) is configurable. Upon expiration, a background process (cron or queue) changes the status to cancelled and returns the quantity to store_inventory. This eliminates manual cancellation and product loss. Reservation via queue is 3 times more reliable than manual release.
Compare three approaches to reservation:
| Approach | Consistency | Complexity | Automatic Cancellation | System Load |
|---|---|---|---|---|
| No reserve | Low (hours of discrepancy) | Low | No | Minimal |
| Manual release | Medium (depends on operator) | Medium | No | Low |
| Auto-release (ours) | High (seconds) | Medium | Yes (queue) | Moderate |
Our approach with a queue, for example via Redis and Laravel queues, processes cancellations in 200 ms and reduces database load.
Case study: a chain of 15 stores, integration with 1C
In one project, we implemented in-store pickup for a grocery store chain. Initial architecture: website on Next.js 14, backend on Laravel 11, accounting system on 1C. The main problem—inventory was updated once an hour, leading to discrepancies of up to 20%.
We implemented two-level synchronization:
- Real inventory (1C) → updates every 15 minutes via REST API
- Reserves (site) → live update when an order is placed
To reduce load on 1C, we used Redis as a cache. When ordering, we check inventory through Redis; if successful, we reserve and send an event to the queue for write-off in 1C. If 1C is unavailable, the order is not confirmed.
Results: cancellations due to "out of stock" dropped by 40%, and order processing speed did not exceed 1.2 seconds. Over 50 similar projects in our portfolio.
What is included in a turnkey implementation?
We provide a full cycle of work:
- Admin panel for managing points (CRUD, map, working hours)
- Widget for point selection on a map with clustering for many points
- Real-time availability check for each product
- Reservation with automatic release via queue
- Ready notifications (email, SMS, Telegram)
- Integration with the accounting system (1C, SAP, any REST API)
- API documentation and monitoring setup
Implementation process
| Stage | Duration | Result |
|---|---|---|
| Analysis | 1-2 days | Technical specification, integration scheme |
| Design | 2-3 days | DB architecture, API, queue |
| Implementation | 3-5 days | Functionality working on test environment |
| Testing | 1-2 days | Unit tests, load testing up to 1000 orders/hour |
| Deployment | 1 day | Production, monitoring, documentation |
Typical mistakes during implementation
- Reservation without a lifetime — product "hangs" forever.
- Using local time for working hours — issues with time zones.
- No queue for releasing reservations — risk of data loss on failure.
- Direct queries to 1C on every checkout — high latency (up to 5 seconds) and load.
Contact us for a preliminary assessment — it will take 30 minutes. Get a consultation with an engineer and accurate timelines for your task.