Why Bitrix delivery intervals diverge from reality
Bitrix delivery intervals are not taken "out of thin air": the site calculates boundaries based on the delivery service profile — working days, window step, order cut-off time, binding to a specific warehouse.
If at least one parameter diverges from the actual warehouse schedule, the customer sees a window that the courier physically cannot fulfill.
A typical discrepancy between the warehouse schedule and the site accumulates quietly. The warehouse switched to a different receiving schedule, holidays were added, the region's time zone changed — but the delivery interval settings remained the same.
A separate issue is manual manager edits in an order: they do not change the window grid, and the next customer again sees the wrong time.
The worst is the reset of delivery settings after an update. A module update overwrites handlers, some "warehouse — service" bindings are lost, the checkout page cache serves the old grid.
Externally everything works: orders are accepted, emails go out, but the promised time again diverges from reality. The cost is calls "where is the courier," cancellations at the delivery stage, and manual window rescheduling that eats up operators' time.
We explain how this is resolved: where to keep a single source of boundaries, how to link delivery windows in checkout with the warehouse schedule, and what to check after each update.
What a managed order fulfillment schedule provides
When intervals are set by rules rather than a manual list, the promise "we will deliver from 14:00 to 16:00" no longer depends on who is on shift today. 1C-Bitrix stores the schedule next to the order, so the dispatcher and the customer see the same picture.
Accuracy of the promised delivery time
The window is calculated from the actual route, vehicle load, and warehouse operating mode, not from the regional average. The share of orders delivered within the promised interval grows, and incoming calls "where is my order" disappear from operators' workload.
Predictable warehouse workload
The schedule determines how many orders fall into each window — the morning peak and afternoon idle time are leveled out. The warehouse and couriers plan shifts based on actual load, not on the dispatcher's experience.
Reducing the share of order reschedules
Rescheduling remains possible but becomes justified: the system offers the nearest available window instead of an arbitrary one. Manual edits per day decrease several times over, and the reason for each shift is visible in the order history.
Automatic calculation of windows
Rules are picked up in all channels — website, customer account, checkout through a manager. The customer selects only those intervals that are actually available, so impossible promises do not arise.
Interval configuration options: how they differ
In 1C-Bitrix, delivery windows are assembled by several mechanisms, and the choice between them determines store behavior when a window is overfilled or the service changes its schedule.
The interval profile defines the window grid for a specific service, the delivery calendar defines working and non-working days, and schedule inheritance pulls parent service settings into child services. Below is a comparison of how each option behaves in real store configurations.
| Option | When it fits | Limitations |
|---|---|---|
| Interval profile per delivery service | Multiple services with different window grids, their own step and planning depth | Windows are calculated from the profile, not from the warehouse: with multiple dispatch points, a separate profile is needed for each |
| Delivery calendar | Holidays, sanitary days, different schedules by region and pickup points | By itself, it does not limit the number of orders per window — the limit is set by a separate setting |
| Schedule inheritance from service | A network of branches with identical windows, only the zone differs | Editing parent settings overwrites child settings — local changes are lost |
| Window overlap rules | Need to suppress intersections when a courier interval overlaps with pickup | The check runs at checkout: already created orders are not recalculated |
In practice, these mechanisms are combined: the profile holds the base grid, the calendar holds exceptions, and the order limit per window prevents courier overload.
Before implementation, we run scenarios with multiple warehouses and time zones — this shows where windows will start overlapping or disappear from the selection.
How implementation proceeds: work stages
Configuring delivery intervals in 1C-Bitrix almost always accumulates history: the warehouse calendar was edited manually, some windows were changed directly in the database, some through delivery profiles.
As a result, no one can explain why today an address gets a slot, and tomorrow the same address does not. We carry out the work in a fixed sequence, where each step ends with a check.
- Delivery settings audit. We export profiles, interval binding rules, the production calendar, and the order log. We look for where the calculation diverges from the actual warehouse operation and which windows were closed manually.
- Window calculation scheme. We fix the rules: from which event the interval is calculated — payment or confirmation, how much time is needed for assembly, how many orders the warehouse takes in one window, how weekends and reschedules are handled.
- Calendars and bindings. We fill in the production calendar, shipment days of warehouses, zones, and service mapping. We make edits in a separate settings branch so that the production storefront continues to accept orders.
- Testing on a staging environment. We transfer the configuration to a copy and run scenarios: pickup, city courier, regional delivery, pre-order, order at the day boundary. We compare the proposed windows with the calculation scheme.
- Test order. We place control orders for each scenario, go through the path to shipment, review notifications and how the window is rescheduled when the status changes, during cancellation, and re-checkout.
- Handover of regulations. We provide a settings map: where shipment days are changed, how to add a holiday, what to do when the warehouse schedule changes, and whom to notify before editing.
Set of settings, schemes, and regulations
The work does not end with "we configured it and left," but with a set of artifacts that allows you to change delivery intervals on your own: expand windows for the season, add a delivery service, close order acceptance for a specific day.
Each item below is handed over in working form — with filled-in values and verification in the test environment.
- Window configuration — a matrix of intervals by warehouses and delivery services, binding to geozones and order cut-off rules when a window is already closed for assembly.
- Availability calculation scheme — how the list of intervals for a specific date is derived from the warehouse calendar, assembly time, weekends, and exceptions; with extension points for new rules.
- Access rights to settings — role separation: who edits windows, who only sees the result, which actions are logged, and why a logistics specialist should not change the warehouse calendar.
- Delivery documentation — description of reference data, relationships between services, zones, and intervals, and the procedure for transferring settings between environments.
- Manager instructions — step-by-step scenarios for holidays and promotions, what happens to already placed orders, and how to check changes before publication.
- Edit and rollback regulations — the procedure for making changes, mandatory verification on a copy, and the rollback point to the previous configuration.
- Parameter map — where each settings key is located in the administrative area, so that finding the required value does not take half a day.
The set remains with you and is updated as changes occur — for example, when connecting a new delivery service, it is enough to extend the matrix and rebuild the scheme.
Case study: how the share of order reschedules was reduced
The client is a network of production facilities with city delivery: several dispatch points, its own couriers, and a contractor service. The settings had one broad interval for the whole day, so the system offered a time that the point physically could not fulfill.
Dispatchers leveled this out manually: they called the customer and rescheduled the order. About every fourth order was affected this way, and complaints about receipt time held second place among inquiries.
What was rebuilt
Intervals were tied to the schedule of each dispatch point and courier zones, a cut-off time was added before the start of the window, and the number of orders per interval was limited by the actual shift capacity.
When the limit is reached, the window disappears from the selection — the customer immediately sees a feasible time.
1C-Bitrix was configured so that the schedule updates together with production: a change in a point's schedule, weekends, and load growth do not require manual edits.
Result after a month
The share of reschedules fell from 24% to 6%, and only those remained where the customer himself asks for a different time.
Complaints about receipt time decreased threefold, and order confirmation at the point accelerated from 8 to 2 minutes — dispatchers stopped manually distributing orders across shifts.
A separate report on interval load was produced: it shows where capacity is underutilized and where windows close within an hour — the schedule is revised based on numbers, not feelings.
How does automatic window generation differ from a manual schedule?
Automatic window generation builds the schedule from data, not from the administrator's memory: the service takes the warehouse calendar, assembly time, cut-off time, and interval step and itself expands the grid for days ahead.
A change in the warehouse schedule or a holiday changes windows immediately in all zones — one edit, not one per zone.
A manual issuance schedule is explicitly defined intervals by days of the week and zones. It is predictable while there are few points and zones: the administrator sees the whole picture and overrides a window for a specific promotion.
Beyond that, manual work grows linearly: a new zone, a seasonal shift, and a pre-holiday day require edits, and a forgotten window means an order that no one can deliver.
| Mode | When it fits | Limitations |
|---|---|---|
| Automatic window generation | Many zones, floating warehouse schedule, peaks | Requires filled-in calendars and correct assembly times: an error is replicated across all windows |
| Manual issuance schedule | One or two zones, stable schedule, promotions | Edits per zone and day manually; risk of error grows with the number of intervals |
| Hybrid | Automatic core plus manual exceptions | A priority rule is needed, otherwise edits conflict with the automatic grid |
The choice of schedule mode is between manageability and flexibility: in 1C-Bitrix, both modes work with the same checkout, so the transition comes down to changing the schedule source, not reworking the storefront.
Under load, the picture is unambiguous: when there are many zones and intervals, a manual schedule cannot be maintained, and it is replaced by an automatic core with manual exceptions for top zones.
We keep the order limit per window separate — otherwise the automatic grid will offer a time for which there will not be enough couriers.
Common technical questions about window configuration
Delivery window configuration lives in two layers: delivery service parameters and binding to a specific warehouse. Because of this, some doubts arise after launch — during a module update or a change in conditions on the warehouse side. Below we discuss what most often surfaces in support.
After a module update, the intervals were reset — can they be restored as they were?
Settings are tied to the delivery service profile and warehouse, and an update pulls in default values and overwrites some fields.
Therefore, before work, we take a copy of the delivery settings and profile tables, and afterward we compare control values and apply discrepancies point by point.
A separate rule: keep the window grid in one source, and do not edit it in parallel in the store interface and in the 1C export — otherwise, during the next update, some edits will simply be lost.
A store has several warehouses with different schedules — is that possible?
Yes, each warehouse is assigned its own set of intervals, grid step, and order acceptance cut-off time.
The customer is shown only the windows of the warehouse that actually ships the goods to their address and stock, and the rest are filtered out at the availability calculation stage.
If this is not done, the person will select a window of an unavailable warehouse and receive a rejection after checkout.
How do windows combine with the delivery service schedule?
The carrier's schedule is an external constraint, and it must be transferred into the grid rather than relying on a check when submitting the request.
Working days, last pickup time, regional exceptions, and holidays form the boundaries within which it makes sense to show intervals at all. Otherwise, the window will be displayed, the request will go out, and the service will reject it.
How can you make sure windows do not overlap?
Overlap checking is configuration validation: we compare pairs of intervals within one day and warehouse, catch overlaps, zero duration, and gaps where the customer cannot select anything.
Then we run a test set of addresses and carts with edge cases — an order one minute before cut-off, two warehouses in one cart, an interval at the day boundary.
Let's discuss the task and come back with an estimate and plan
For the estimate to be accurate rather than "plus or minus," a complete picture is needed: where delivery intervals are currently set, which services are connected, how intervals are linked to the warehouse schedule and holiday exceptions.
Describe the task in free form — what does not work now and what the result should be. This is enough for us to come back with an estimate and work plan.
What to send to start:
- list of delivery services and regions for which their own intervals apply;
- current interval settings and exceptions by date — screenshots or descriptions;
- examples of orders where the interval is set incorrectly, with date and city;
- operating mode of the warehouse and pickup points;
- roles: who changes intervals and who approves changes;
- access for the audit — test environment and delivery settings panel.
The estimate is based on the scope of configuration and the number of scenarios: how many interval groups, whether separate rules are needed for product categories, and whether there is data exchange with delivery services.
After the audit, we send a work plan: stages, what we do at each, what data is needed from you, implementation timelines, and approval points.
First we check everything on a copy of the site, then transfer to production — intervals begin to be calculated correctly without manual edits.
Describe the task — we will come back with an estimate and work plan.