POS during an internet outage: a business continuity playbook for local operatorsPOS без интернета: план непрерывной работы для локального бизнеса
A practical guide to offline POS continuity: what must remain available, which payments are safe, how to queue transactions, reconcile stock, restore integrations, and review every exception after connectivity returns.Практическое руководство по работе POS без интернета: что должно оставаться доступным, какие платежи допустимы, как ставить операции в очередь, сверять остатки, восстанавливать интеграции и разбирать исключения после возвращения связи.
No. Keep low-risk selling available, but limit actions that require live authorization, unique inventory truth, remote approval, delivery dispatch, or cross-location coordination. The business must know which records are local, which are queued, and which promises cannot be verified until the connection returns.Нет. Сохраняйте низкорисковые продажи, но ограничивайте действия, которым нужны онлайн-авторизация, точные остатки, удаленное согласование, диспетчеризация доставки или связь между точками. Бизнес должен понимать, какие записи локальные, какие стоят в очереди и какие обещания нельзя проверить до восстановления связи.
Detect, limit, queue, reconcile, and learnОбнаружить, ограничить, поставить в очередь, сверить и улучшить
The outage plan should be visible inside the POS so the team does not depend on memory during a stressful shift.План сбоя должен быть виден внутри POS, чтобы команда не полагалась на память в напряженную смену.
Connectivity detectedОбнаружен сбой
The device distinguishes local network, internet, payment processor, and backend failures.Устройство различает сбой локальной сети, интернета, процессинга и сервера.
Risk mode appliedПрименен режим риска
The POS enables an owner-approved subset of catalog, discounts, payments, and permissions.POS включает утвержденный владельцем набор каталога, скидок, оплат и прав.
Transactions queuedОперации в очереди
Orders and allowed tenders receive immutable local records and visible sync status.Заказы и допустимые оплаты получают неизменяемые локальные записи и статус синхронизации.
Connection restoredСвязь восстановлена
The system re-authenticates and replays records without silently overwriting newer truth.Система заново проверяет доступ и отправляет записи без скрытой перезаписи новых данных.
Exceptions reconciledИсключения сверены
A named owner resolves payment, inventory, tax, receipt, and delivery discrepancies.Назначенный ответственный решает расхождения оплат, остатков, налогов, чеков и доставки.
Keep only the workflows the location can prove locallyОставьте только те процессы, которые точка может подтвердить локально
Before an outage, classify catalog access, price rules, tax settings, employee permissions, receipt generation, cash handling, customer lookup, loyalty, returns, and payments by their dependence on live data. A location should continue a simple sale only when the device holds a current trusted snapshot and the owner has accepted the risk.До сбоя разделите каталог, цены, налоги, права, чеки, наличные, поиск клиентов, лояльность, возвраты и платежи по зависимости от онлайн-данных. Точка продолжает простую продажу только при наличии актуального доверенного снимка и принятого владельцем риска.
- Local snapshot. Cache only the fields needed for approved offline actions and show snapshot age.Локальный снимок. Храните только нужные для офлайн-действий поля и показывайте возраст данных.
- Permission boundary. Do not elevate staff privileges merely because the server cannot be reached.Граница прав. Не расширяйте права сотрудника только потому, что сервер недоступен.
- Promise boundary. Block stock, delivery, or cross-location promises that cannot be verified.Граница обещаний. Блокируйте обещания по остаткам, доставке и другим точкам, если их нельзя проверить.
Treat offline payment as credit risk, not a technical convenienceСчитайте офлайн-платеж кредитным риском, а не техническим удобством
A delayed authorization may later fail. Define allowed tender types, per-transaction and shift limits, card and customer risk rules, required signatures or receipts, and who can override. Make the status visible to staff and finance so an offline acceptance is never mistaken for settled revenue.Отложенная авторизация может быть отклонена позже. Задайте допустимые типы оплаты, лимиты операции и смены, правила риска карты и клиента, необходимые подтверждения и права на исключение. Статус должен быть виден сотруднику и финансам, чтобы офлайн-принятие не считалось окончательной выручкой.
Separate accepted and settledРазделяйте принято и проведено
Finance should see pending authorization as exposure until confirmation arrives.Финансы должны видеть ожидающую авторизацию как риск до подтверждения.
Cap exposureОграничьте риск
Use owner-defined transaction, customer, device, and shift limits.Используйте лимиты по операции, клиенту, устройству и смене.
Communicate honestlyОбъясняйте честно
Receipts and staff language should reflect the actual payment state.Чек и слова сотрудника должны отражать реальный статус оплаты.
Replay records idempotently and make conflicts explicitПовторяйте записи идемпотентно и показывайте конфликты явно
When connectivity returns, duplicate taps and retries must not create duplicate orders or payments. Use stable transaction identifiers, ordered event logs, retry states, and conflict rules. If stock, customer, discount, or tax data changed while offline, route the case to review instead of silently choosing one version.После восстановления связи повторные нажатия и попытки не должны создавать дубли заказов или оплат. Нужны стабильные идентификаторы, упорядоченный журнал событий, статусы повторов и правила конфликтов. Если остаток, клиент, скидка или налог изменились офлайн, отправьте случай на проверку вместо скрытого выбора версии.
IdempotencyИдемпотентность
The same offline record can be retried without creating a second business event.Одну офлайн-запись можно повторить без создания второго бизнес-события.
Visible queueВидимая очередь
Staff can see pending, sent, confirmed, rejected, and review-required states.Сотрудник видит ожидание, отправку, подтверждение, отклонение и проверку.
Conflict ownerВладелец конфликта
Every unresolved mismatch has a role and deadline.У каждого нерешенного расхождения есть роль и срок.
Run outage drills during calm hoursПроводите учения по сбою в спокойные часы
A written policy is insufficient if devices have stale data, batteries fail, staff cannot identify offline status, or the recovery queue has never been tested. Simulate internet loss, processor loss, device replacement, and partial restoration. Record the first blocked sale, first unsafe workaround, and reconciliation time.Письменной политики мало, если на устройствах старые данные, не хватает батареи, сотрудник не узнает офлайн-статус или очередь восстановления никогда не проверялась. Смоделируйте потерю интернета, процессинга, замену устройства и частичное восстановление. Зафиксируйте первую заблокированную продажу, первый опасный обход и время сверки.
Device readinessГотовность устройств
Check charge, local storage, receipt options, trusted time, and last snapshot.Проверьте заряд, память, печать, доверенное время и последний снимок.
Staff languageСлова сотрудника
Give clear phrases for unavailable actions and safe alternatives.Дайте понятные формулировки для недоступных действий и безопасных альтернатив.
Recovery timingВремя восстановления
Measure when selling resumed and when financial truth was fully reconciled.Измеряйте возобновление продаж и полное восстановление финансовой правды.
Decide what continues, queues, or stopsОпределите, что продолжается, ставится в очередь или останавливается
The safest decision depends on the need for live authorization and the cost of inconsistent data.Безопасность зависит от необходимости онлайн-проверки и цены рассогласованных данных.
| WorkflowПроцесс | Continue locallyПродолжить локально | Queue for syncПоставить в очередь | Block or reviewЗаблокировать или проверить |
|---|---|---|---|
| Simple cash saleПростая продажа за наличные | UsuallyОбычно | Order, receipt, inventory eventЗаказ, чек, движение остатка | If catalog or tax snapshot is staleЕсли каталог или налог устарели |
| Card paymentОплата картой | Only under approved offline policyТолько по утвержденному правилу | Authorization and settlementАвторизация и проведение | High value, limit exceeded, unsupported cardВысокая сумма, лимит, неподдерживаемая карта |
| Return or refundВозврат | RarelyРедко | Request and evidenceЗапрос и доказательства | Needs original transaction and approvalНужны исходная операция и согласование |
| Delivery promiseОбещание доставки | Only with local verified capacityТолько с локально подтвержденной загрузкой | Dispatch requestЗапрос диспетчеризации | Unknown courier or service areaНеизвестны курьер или зона |
| Loyalty redemptionСписание бонусов | With strict local limitsС жесткими локальными лимитами | Balance adjustmentИзменение баланса | Unknown balance or fraud signalНеизвестный баланс или риск мошенничества |
Build the outage mode before the next outageСоздайте офлайн-режим до следующего сбоя
Use the last real outage to prioritize the smallest set of functions that protects revenue without hiding risk.Используйте последний реальный сбой, чтобы выбрать минимальный набор функций, сохраняющий выручку без скрытого риска.
Classify dependenciesРазобрать зависимости
Mark which actions require backend, processor, inventory, identity, or manager access.Отметьте действия, которым нужны сервер, процессинг, остатки, личность или менеджер.
Set limitsЗадать лимиты
Approve tender, amount, role, device, snapshot-age, and promise boundaries.Утвердите тип оплаты, сумму, роль, устройство, возраст данных и границы обещаний.
Test queue and replayПроверить очередь
Create duplicates, conflicts, rejection, and partial recovery in a controlled drill.Создайте дубли, конфликты, отклонения и частичное восстановление на учениях.
Train and reviewОбучить и разобрать
Teach staff the visible status and review every outage exception with finance and operations.Научите сотрудников видеть статус и разбирайте исключения с финансами и операциями.
Questions to resolve before implementationВопросы, которые стоит закрыть до внедрения
Can card payments work offline?Могут ли карты работать офлайн?
Some setups can queue or delay authorization, but the business accepts risk until the processor confirms. Configure this with the payment provider and owner-approved limits.Некоторые схемы допускают очередь или отложенную авторизацию, но бизнес несет риск до подтверждения процессингом. Настройте это с платежным провайдером и лимитами владельца.
Will inventory stay accurate?Останутся ли остатки точными?
The local device can record a movement, but cross-device and cross-location truth is provisional until synchronization and conflict review finish.Локальное устройство запишет движение, но данные между устройствами и точками остаются предварительными до синхронизации и разбора конфликтов.
What should staff see on screen?Что должен видеть сотрудник на экране?
Show offline cause, snapshot age, available actions, payment exposure, queued count, and clear recovery status.Покажите причину офлайна, возраст данных, доступные действия, риск оплаты, число операций в очереди и статус восстановления.
How often should we test?Как часто проводить тест?
Test after material configuration changes and on a regular schedule appropriate to business risk, location count, and payment volume.Проверяйте после важных изменений и регулярно с учетом риска, числа точек и объема платежей.
Open the pages connected to this workflowОткройте страницы, связанные с этим процессом
Use product and industry pages to validate the scenario against your team, locations, and customer journey.Сверьте сценарий с вашей командой, точками и клиентским путем на продуктовых и отраслевых страницах.
Design an outage mode your staff can actually followСпроектируйте офлайн-режим, который команда сможет выполнить
We will map your payment, catalog, inventory, receipt, delivery, and reconciliation dependencies, then show which SABSUS controls should continue, queue, or stop.Мы разберем зависимости оплаты, каталога, остатков, чеков, доставки и сверки, затем покажем, какие действия SABSUS продолжает, ставит в очередь или останавливает.