Как малому сервисному центру проверить доступы к CRM после увольнения

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

Почему доступы нужно проверять сразу после ухода сотрудника?

В ремонтной мастерской один заказ проходит через несколько рук. Приёмщик создаёт карточку, мастер указывает диагностику и выполненные работы, кладовщик списывает запчасть, руководитель смотрит деньги и загрузку. В отраслевых системах для сервисных центров роли часто разделяют именно между сотрудником call-центра, приёмщиком, мастером, сотрудником технического отдела и руководителем (1С:Предприятие 8. Управление сервисным центром).

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

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

В каком порядке отключать доступы к CRM и связанным сервисам?

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

1. Зафиксируйте дату и время, когда сотрудник перестал работать.
2. Заблокируйте его личный вход в CRM и завершите все сеансы.
3. Проверьте права в разделах заказов, кассы, склада, скидок и отчётов.
4. Отключите доступ к почте, рабочим чатам и сервисам, откуда можно отправлять сообщения клиентам.
5. Смените пароли общих учётных записей, если сотрудник их знал.
6. Передайте открытые заказы конкретному сотруднику и проверьте, что они не остались без ответственного.

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

Какие права оставить приёмщику, мастеру, кладовщику и руководителю?

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

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

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

Как настроить журнал действий, чтобы он помогал в спорных случаях?

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

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

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

Типичные ошибки при аудите доступов

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

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