Прежде чем начать заводить договоры или какие-то настройки, необходимо завести пользователей агентства, то есть тех сотрудников, которые будут обрабатывать заказы.
Собственно, это и является основной задачей ваших пользователей, и основной интерфейс, с которым они будут иметь дело – это список заказов и деталей заказа, оттуда и осуществляется весь процесс обработки.
Существуют две основные концепции обработки заказов:
Процессно-ориентированный подход, когда агент обслуживает заказ «от и до».
Соответственно, независимо от того, что с заказом произошло, за него отвечает именно назначенный на этот заказ сотрудник;Функционально-ориентированный подход, когда сотрудник назначен на какую-то функцию.
Например, бухгалтер отвечает за пополнение кредитных линий и обрабатывает все заказы, в которых размер кредитной линии недостаточен для оформления услуги (например, связывается с клиентом и просит его пополнить депозит/выплатить долг и так далее). Этот механизм называется «задачами».
На начальном этапе работы мы рекомендуем игнорировать функциональную ориентацию, так как она более сложна для реализации и нужна только в том случае, если у вас в системе выписывается не менее 100 заказов в сутки. На первом этапе не стоит добавлять сложностей этой функцией.
В чистом виде функционально-ориентированный подход возможен только в retail-продажах, однако его элементы применимы и в корпоративном обслуживании, как, например, приведенный выше пример с бухгалтером: сам сотрудник бухгалтерии не сможет помочь клиенту с оформлением билета; в то же время авиаагент не может понять в общем случае, может или не может оформлять билеты с учетом того, что его депозит только что закончился.
Поэтому для работы авиаагентов логично применять процессный подход, а для бухгалтерии – функциональный. То есть агент делает с заказом все, кроме управления кредитными лимитами и долгами, а как только возникает проблема с лимитом – к заказу подключается бухгалтер и добивается урегулирования этого вопроса.
Это – идеальная схема работы, но не пытайтесь реализовать её сразу! Скорее всего, для вас это будет очень сложно, так как чем меньше задействовано людей на первом этапе внедрения, тем лучше оно пойдет.
При этом верно и обратное утверждение: чем меньше людей задействовано во внедрении через год после его начала, тем хуже оно прошло. Поэтому грамотно распределяйте силы по дистанции, следуйте гайдлайнам из этого руководства, и, скорее всего, все будет хорошо.
В системе существует 3 роли пользователей агентства, которые отличаются ограничениями прав:
Рядовой сотрудник
Может обрабатывать заказы, не имеет доступа к настройкам.
Видит только заказы, которые назначены на него, и заказы, которые не имеют исполнителя;Руководитель СТ
Обладает правами сотрудника + видит все заказы в СТ и может передавать их другим исполнителям.
Имеет доступ к кредитным линиям и отчетам по качеству;Администратор
Суперпользователь. Может все то, что руководитель СТ + имеет доступ к административным настройкам системы.
Не давайте эту роль непроверенным людям.
2-3 администратора в агентстве – норма, 20-30 – результат неправильного внедрения.
Рассмотрим примеры заведения пользователей в систему.
В качестве модели возьмем агентство, которое обслуживает корпоратов и субагентов. При этом субагентами занимается одна группа специалистов (СТ), а корпоратами – другая.
Конечно, это не значит, что вы у себя должны создавать точно такие же СТ – например, вы можете создать несколько СТ, которые обслуживают разных корпоратов.
Также у вас может и не быть субагентов, никаких проблем с этим нет.
Пример 1: сотрудник дневной смены, который поддерживает корпоративных клиентов по авиа- и ж/д билетам:
Чтобы пользователи получали меньше уведомлений по электронной почте, можно ограничить типы сообщений, которые они будут получать на email:
Пример 2: бухгалтер, который контролирует задолженности по корпоратам и субам:
Обратите внимание – так как бухгалтер не обрабатывает заказы (он не выпишет билет клиенту, ему не нужно знать про текущую операционную активность), то у него нет привязки к типам услуг, а только к задачам:
Для того, чтобы работать с кредитным лимитом, бухгалтер должен иметь роль «Руководитель СТ»
Пример 3: КАМ, который работает с корпоратами и следит за тем, чтобы их заказы обрабатывались корректно.
