Что руководитель принимает после обслуживания

После обновления менеджер может открыть Битрикс24, но не получить новую заявку или не отправить заказ в учётную систему. Продажи остановятся на отдельном действии, хотя главная страница портала выглядит исправной. Поэтому задача руководителя начинается с вопроса о том, какую работу отдел должен продолжить после обслуживания: принять обращение с сайта, назначить ответственного, сохранить сделку и передать её дальше без повторного ввода. Именно этот путь становится основой приёмки. Название установленной версии объясняет, что изменил подрядчик, а пройденный путь клиента показывает, может ли компания снова обслуживать обращения.

Дальше речь о коробочной CRM с заявками на услуги через сайт и передачей данных во внешнюю систему. Менеджер уточняет запрос и создаёт сделку, после чего её данные уходят во внешнюю систему для подготовки документа. При наличии других каналов приёмку расширяют, а для разбора подготовки достаточно проследить эту цепочку. Если форма отправилась, а ответственный не назначился, обращение осталось без хозяина. После успешного назначения задержка может возникнуть дальше: документ не создаётся, и сотрудник обнаруживает остановку при продолжении работы.

Одного входа недостаточно. В плане обновления коробочного Битрикс24 должны появиться действия отдела продаж, которые подрядчик и представитель заказчика выполнят до возвращения сотрудников к обычной работе.

Что скрывается за обещанием «обновить коробку»

Фраза «обновим коробку» оставляет слишком много разных работ внутри одного обещания. Установка пакетов платформы, смена серверного окружения и доработка приложения могут требовать разных исполнителей и разного времени на восстановление.

В инструкции Битрикс24 обновления устанавливаются через SiteUpdate. Раздел называется «Marketplace → Обновление платформы», а список пакетов позволяет выбрать состав установки. Руководителю полезен отдельный перечень того, что подрядчик собирается изменить, с причиной для каждого пункта и указанием связанной доработки, если она потребуется.

Версии фиксируются заранее. Для выбранного пути продажи в перечне отдельно стоят платформа CRM, приложение обмена с учётной системой и изменение окружения сервера, если без него целевое обновление невозможно, а рядом указано, какие работы включены в стоимость и кто отвечает за их результат. Смена окружения может иметь собственное окно и отдельный способ возвращения. Так заказчик видит границу между запланированным обслуживанием и новой задачей, обнаруженной в процессе, а подрядчик не вынужден угадывать, какое сочетание изменений уже разрешено.

По умолчанию производитель включает установку стабильных обновлений; бета-версии могут содержать ошибки. Их ранний доступ к возможностям имеет смысл обсуждать отдельно. Приёмку продаж нельзя строить на неоговорённом эксперименте только потому, что новый пакет уже доступен для установки.

Требования старой версии могут не подойти новой

Совместимость окружения относится к подготовке, даже если сервер вчера работал без жалоб. Новая версия платформы и установленное приложение обмена могут предъявлять разные требования к одному и тому же серверу.

На актуальной странице технических требований указан PHP 8.2 и выше. При этом инструкция по обновлению ещё называет порог 8.1 для установки пакетов. Подрядчик должен сверить требования целевой версии и используемых расширений до назначения окна работ, а не выбирать меньший номер из двух страниц.

Это техническая задача специалиста. Руководителю достаточно получить ответ, какое окружение сейчас используется, что придётся изменить для выбранного обновления и на чём подтверждена совместимость именно вашего обмена, доработок и установленной версии CRM. Запись «сервер соответствует» без указания целевой версии быстро теряет смысл, когда состав обновления меняется или к работам подключается другой исполнитель.

Доступность обновлений связана и с лицензией: производитель указывает, что для перехода на последнюю версию она должна быть активной. Срок действия и доступ к нужным пакетам лучше сверить до подготовки копии. Когда пакеты недоступны, окно ещё не готово. Выделенное время сотрудников не должно уходить на вопрос, который можно было снять раньше.

Архив полезен только с понятным возвращением к работе

Резервная копия полезна, когда из неё можно восстановить нужное состояние портала. Само наличие файла с сегодняшней датой мало говорит о том, получится ли открыть CRM, увидеть сделки и продолжить работу с приложениями.

В документации резервного копирования встроенная проверка целостности описана как виртуальная распаковка архива. Пробное восстановление показывает, удаётся ли запустить портал из копии. Там же указан предел применимости описанного штатного механизма: база данных MySQL. Для другого типа базы специалист выбирает подходящий способ отдельно.

Возврат занимает время. В плане фиксируются момент создания копии, её состав, место хранения и человек, который сможет запустить восстановление, даже если основной исполнитель окажется недоступен. Для портала продаж важно уточнить сохранность файлов и настроек обмена вместе с базой, а также доступы, необходимые для возвращения приложений к работе. Изолированное пробное восстановление показывает длительность операции и помогает обнаружить недостающий доступ до того, как его срочно потребует остановленный отдел.

Если архив хранится на том же сервере, обсуждается отдельная доступная копия: отказ сервера может закрыть путь и к порталу, и к файлу восстановления. Этот вопрос связан с общим планом резервного копирования, но критерий для текущих работ проще: назначенный человек знает, откуда взять нужное состояние и сколько времени займёт его возвращение.

Наглядный разбор

Четыре основания для начала работ

  1. Состав

    Записаны целевые версии и включённые изменения

  2. Совместимость

    Окружение и доработки испытаны на копии

  3. Возврат

    Копия восстановлена, доступы и длительность известны

  4. Работа отдела

    Назначены сценарии приёмки и приём новых заявок

Пример состава подготовки для коробочной CRM с внешним обменом.

Живой обмен опасно впервые запускать после установки

Тестовая копия нужна для репетиции выбранного состава работ. На ней можно увидеть, сохраняется ли путь заявки после установки пакетов, прежде чем тот же путь понадобится настоящему клиенту.

Копия требует изоляции. Если перенесённое приложение получит рабочие доступы к внешней системе, тестовая сделка может породить настоящий документ или уведомление клиенту. Поэтому исполнитель заранее описывает, как отключены исходящие сообщения и реальные операции, какие безопасные данные используются для обмена и какие связи остаются доступными только для испытания, чтобы запуск робота на копии не стал незапланированным действием в рабочей системе.

Для CRM с заявками сайта достаточно начать с одной новой заявки и одной сделки, существовавшей до обновления. Первая показывает, проходит ли новый клиент обычный маршрут. Вторая помогает увидеть, можно ли продолжить ранее начатую работу. Для каждого шага фиксируется ожидаемый результат, например назначенный менеджер или номер документа, а при отклонении — место, где цепочка прервалась.

Репетиция не покрывает все различия с рабочим порталом. Если у копии другие ресурсы, не все подключения или устаревшая база, подрядчик указывает эти ограничения в результате испытания и оставляет соответствующие действия для приёмки на рабочей системе. Подробный набор ролей и маршрутов можно оформить по принципам тестирования CRM.

Отдельные кнопки не показывают весь путь сделки

Проверка CRM после обновления начинается с действия сотрудника под его обычной ролью. Вход администратора мало помогает понять, может ли менеджер увидеть свою заявку и сохранить нужное изменение.

Для выбранного пути продажи представитель заказчика отправляет безопасную тестовую заявку с сайта, находит её в CRM и убеждается, что ответственным стал нужный сотрудник, а затем этот сотрудник открывает карточку, меняет этап и сохраняет данные, которые передаются во внешнюю систему. На стороне получателя ищут результат по заранее выбранному признаку, например номеру тестовой сделки, чтобы зелёное сообщение об отправке не подменило получение данных.

Нужен конечный результат. Если обмен завершился, но поле оказалось пустым или документ создался повторно, путь продажи ещё содержит проблему. Ожидания описываются предметно: какие данные должны совпасть, сколько документов должно появиться и кто видит результат в пределах своей роли.

В приёмку также входит повторное открытие сохранённой карточки. Сотрудник подтверждает, что изменения остались после обновления страницы, а исполнитель смотрит состояние фоновых задач и обмена, если они участвуют в этом маршруте. Для автоматических действий полезен отдельный материал о тестировании роботов Битрикс24; здесь выбирают только действия, без которых отдел не сможет продолжить продажи.

Окно работ требует людей и приёма заявок

Ночное обслуживание удобно только тогда, когда ночью доступны исполнители и представитель бизнеса. Без человека, который принимает путь сделки, техническая часть может закончиться, а разрешение работать останется до утра.

Окно включает подготовительные действия на рабочем портале, установку, приёмку и время на решение о возврате, если критичный сценарий не пройдёт. Продолжительность берётся из репетиции с запасом на известные отличия, а не из общего обещания «это быстро». Руководитель заранее назначает границу, после которой уже нельзя продолжать попытки исправления и одновременно рассчитывать вернуть отдел к началу смены.

Входящие обращения не ждут. Для сайта, почты и телефонии компания определяет, какие заявки продолжат приходить во время работ, где они сохранятся и кто перенесёт их в CRM, если привычная доставка временно недоступна.

Действие в окнеКто отвечаетЧто фиксируется
Начало ограничения работыРуководитель отделаСотрудники предупреждены, временный приём включён
Установка выбранного составаПодрядчикФактические версии и отклонения от плана
Приёмка пути сделкиМенеджер и специалистИдентификаторы тестовых записей и итог обмена
Решение о продолженииНазначенный руководительОткрыть доступ или начать восстановление

Таблица описывает роли, которые один человек может совмещать, если его доступность и полномочия понятны обеим сторонам.

Возврат старой базы затрагивает новые действия

Возврат к копии восстанавливает более раннее состояние данных. Если после её создания сотрудники успели принять заявки или поменять сделки, эти действия потребуют отдельного разбора при восстановлении.

Сначала определяется точка возврата. Для работ, где возможно восстановление базы, руководитель обсуждает ограничение изменений на время обслуживания и способ учёта новых обращений, а если полная остановка невозможна, подрядчик заранее предлагает порядок фиксации и последующего переноса таких данных. Обещание «откатим при необходимости» без этого порядка оставляет бизнесу неприятный выбор между исправной старой системой и сохранением того, что успело появиться в новой.

Особенно внимательно рассматриваются действия за пределами CRM. Внешняя система могла уже создать документ, а восстановленный портал будет считать, что его ещё нет. Повторная отправка способна создать дубль. После возврата исполнитель сверяет состояние обеих сторон по идентификаторам и решает, какие действия допустимо повторить, прежде чем включать обычный обмен.

Условия возврата описываются через остановку продажи: нельзя принять обращение, сохранить сделку или получить обязательный результат внешнего обмена. Небольшой дефект оформления может допускать продолжение работы с отдельной задачей на исправление, если он не мешает сотрудникам. Это решение принимает назначенный представитель бизнеса по фактическим последствиям, а подрядчик предоставляет техническую оценку и оставшееся время.

Наглядный разбор

Решение после установки

  1. Путь сделки пройден

    Ответственный разрешает обычную работу и наблюдение

  2. Есть допустимое отклонение

    Согласуются временный порядок и задача на исправление

  3. Продажа остановлена

    До границы окна запускается подготовленный возврат

  4. После возврата

    Сверяются новые обращения и действия внешней системы

Схема нужна для выбора действия, когда технические работы завершились.

Можно ли начинать обслуживание сегодня

Подготовка обновления портала заканчивается готовностью людей выполнить план. Дата в календаре сама по себе её не создаёт.

Перед назначенным окном руководителю полезно ответить на четыре вопроса: известен ли точный состав изменений, испытан ли путь продажи, доступен ли возврат к копии и определено ли место для новых заявок на время работ. Если ответ опирается только на устное «разберёмся», соответствующая часть подготовки ещё не завершена.

Результат приёмки остаётся у заказчика. Короткая запись включает фактические версии, выполненные сценарии с тестовыми идентификаторами и открытые отклонения. В ней также называют ответственного за наблюдение после запуска и способ обращения при повторном сбое, чтобы утренний менеджер не искал нужного специалиста, заново читая ночную переписку.

В первые рабочие операции стоит включить просмотр доставки новых обращений и завершения обмена по принятому маршруту. Постоянное наблюдение за такими связями описано в материале о мониторинге интеграций CRM. Если для обновления нужен подрядчик, эти основания можно включить в задачу на развитие Битрикс24: тогда результатом работ станет доступный отделу путь продажи с понятным способом восстановления.

Источники и полезные ссылки

  1. Битрикс24: обновление коробочной версии и стабильные пакеты ↗
  2. Битрикс24: технические требования коробочной версии ↗
  3. 1С-Битрикс: создание и проверка резервной копии ↗

Интерфейсы и возможности сервисов могут меняться. Перед настройкой сверяйтесь с актуальной документацией.

Игорь Крещенко

Руководитель ШТАБ ИТ. Занимается управлением проектами, веб-разработкой, рекламой и PR. Подробнее об авторе →