SABSUS
Help me chooseПомочь выбрать Book a demoПолучить демо
SABSUS · CHANNELS AND OPERATIONSSABSUS · КАНАЛЫ И ОПЕРАЦИИ

When the POS loses its connectionКогда касса теряет связь

An outage plan begins with what this deployment has actually demonstrated. A visible catalog does not prove that an order can be saved, a card authorized or stock reserved without connectivity. Decide what may continue, what must stop and who owns reconciliation before the next interrupted shift.План на случай сбоя начинается с того, что реально проверено в этой конфигурации. Видимый каталог не доказывает возможность сохранить заказ, авторизовать карту или зарезервировать остаток без связи. До следующего сбоя решите, что продолжать, что остановить и кто проведёт сверку.

Published: Опубликовано: Updated: Обновлено: SABSUS

Identify what stopped workingОпределите границу сбоя

Distinguish a terminal problem, local network failure, internet interruption and unavailable payment or application service. They can produce similar symptoms while leaving different functions available. Staff should record the affected device, time and observed message, then use the named support route rather than guessing from a single icon.Различайте проблему терминала, локальной сети, интернета и недоступность платёжного или прикладного сервиса. Симптомы похожи, но доступные функции различаются. Сотрудник фиксирует устройство, время и сообщение и обращается по согласованному каналу, не делая вывод по одной иконке.

The manager maintains a short capability matrix for the installed versions: catalog access, order recording, printing, payments, stock checks and dispatch. Mark each as verified, unavailable or untested under the specific failure. An untested operation should not become part of the outage promise.Руководитель ведёт короткую матрицу установленной версии: просмотр каталога, запись заказа, печать, оплата, проверка остатков и отправка в доставку. Для конкретного сбоя отметьте «проверено», «недоступно» или «не проверено». Непроверенную операцию нельзя включать в обещание работы при сбое.

Give payments a separate stop ruleЗадайте отдельное правило для оплаты

Offline card acceptance depends on the actual terminal, processor, agreement and configuration. This guide does not establish that SABSUS or your processor supports it. Obtain current provider documentation and a verified deployment test before permitting it; a stored order is not evidence that payment has been authorized.Приём карты без связи зависит от терминала, провайдера, договора и настройки. Этот материал не подтверждает такую возможность SABSUS или вашего провайдера. До разрешения нужны актуальные документы провайдера и проверка конфигурации; сохранённый заказ не означает авторизованную оплату.

For a customer whose bank appears to show a debit while the POS has no final result, keep the payment reference and assign investigation. Repeatedly attempting collection can create a second problem. Staff need an approved way to explain the uncertainty and a clear limit on goods or services released while it remains unresolved.Если банк клиента показывает списание, а у кассы нет итогового результата, сохраните ссылку на платёж и назначьте проверку. Повторные попытки могут создать вторую проблему. Сотруднику нужны согласованное объяснение и предел выдачи товара или услуги до выяснения результата.

Reduce promises that need live factsОграничьте обещания по живым данным

An illustrative shop loses its connection while two channels offer the last unit. Until availability is known, the shift lead may need to pause that item or take an explicitly unconfirmed request under an agreed procedure. Do not call a local stock snapshot a cross-channel reservation.В условном магазине пропадает связь, когда два канала предлагают последнюю единицу. Пока наличие неизвестно, руководителю смены может понадобиться остановить позицию или принять явно неподтверждённый запрос по согласованной процедуре. Локальный снимок остатков не равен резерву для всех каналов.

Apply the same discipline to bookings, remote approvals and courier dispatch. Agree which commitments require current information and who can resume them. Keep customer wording aligned with the reduced service so that staff do not promise a time that another team cannot see or fulfill.Так же поступайте с записью, удалённым согласованием и назначением курьера. Определите обязательства, требующие текущих данных, и того, кто возобновит их приём. Объяснение клиенту должно соответствовать ограничениям, чтобы сотрудник не обещал срок, которого другая команда не видит.

Restore service before closing the incidentВосстановите работу и закройте расхождения

Where the configuration demonstrably retains pending operations, inventory them by reference, device, time and state. Where it does not, follow the separately approved contingency record. Never collect card credentials in a workaround. Reconciliation must distinguish an operation awaiting transmission from one rejected by the receiving service.Если конфигурация действительно сохраняет ожидающие операции, составьте перечень по номеру, устройству, времени и состоянию. Если нет, используйте отдельно согласованный резервный учёт. Не собирайте реквизиты карт в обходном процессе. При сверке различайте ожидание передачи и отказ принимающего сервиса.

Restore in the agreed order and compare orders, payment results, stock movements and downstream tasks. A restored connection is only the start of recovery. Finance owns payment differences, the stock owner investigates quantity conflicts, and the shift lead confirms that no customer commitment has disappeared between those checks.Восстанавливайте процессы в согласованном порядке и сопоставляйте заказы, результаты оплат, движения запасов и дальнейшие задачи. Возврат связи — лишь начало. Финансы разбирают оплаты, ответственный за склад — количества, руководитель смены проверяет, что обязательства перед клиентами не потерялись.

Rehearse one bounded interruptionОтрепетируйте ограниченный сбой

Use a safe test setup with external charges and messages disabled. Include an interrupted submission, a restart, an uncertain payment response and a changed stock value. Compare observed behavior with the capability matrix; record versions and unresolved gaps instead of declaring universal offline support.Используйте безопасную тестовую среду без внешних списаний и сообщений. Включите прерванную отправку, перезапуск, неясный ответ оплаты и изменившийся остаток. Сопоставьте наблюдения с матрицей возможностей; зафиксируйте версии и пробелы вместо заявления об универсальной работе без связи.

Keep the runbook accessible without relying on the failed service. Name the decision maker, escalation contact, customer wording and recovery sign-off. Review it after a configuration or provider change and after any incident that exposed a different failure mode.План должен быть доступен без отказавшего сервиса. Укажите принимающего решение, контакт для эскалации, объяснение клиенту и условия завершения восстановления. Пересматривайте его после изменения настройки или провайдера и после сбоя, выявившего новый сценарий.

NEXT STEPСЛЕДУЮЩИЙ ШАГ

Map the functions your shift needsОпределите функции для вашей смены

Bring the terminal, processor and deployment details. Discuss a continuity plan only for the behavior that can be demonstrated in that setup.Подготовьте сведения о терминале, провайдере и конфигурации. План непрерывности нужно строить на поведении, которое можно подтвердить именно в ней.