Заведение пользователей агентства

Прежде чем начать заводить договоры или какие-то настройки, необходимо завести пользователей агентства, то есть тех сотрудников, которые будут обрабатывать заказы.
Собственно, это и является основной задачей ваших пользователей, и основной интерфейс, с которым они будут иметь дело – это список заказов, агентские задания, а так же детали заказа, оттуда и осуществляется весь процесс обработки.

Редактор пользователей агента находится в разделе “настройки”

Open

Существуют две основные концепции обработки заказов:

• Процессно-ориентированный подход, когда агент обслуживает заказ «от и до».
  Соответственно, независимо от того, что с заказом произошло, за него отвечает именно назначенный на этот заказ сотрудник;

• Функционально-ориентированный подход, когда сотрудник назначен на какую-то функцию.
  Например, бухгалтер отвечает за пополнение кредитных линий и обрабатывает все заказы, в которых размер кредитной линии недостаточен для оформления услуги (например, связывается с клиентом и просит его пополнить депозит/выплатить долг и так далее). Этот механизм называется «задачами».

В чистом виде функционально-ориентированный подход возможен только в retail-продажах, однако его элементы применимы и в корпоративном обслуживании, как, например, приведенный выше пример с бухгалтером: сам сотрудник бухгалтерии не сможет помочь клиенту с оформлением билета; в то же время авиа агент не может понять в общем случае, может или не может оформлять билеты с учетом того, что его депозит только что закончился.
Поэтому для работы авиа агентов логично применять процессный подход, а для бухгалтерии – функциональный. То есть агент делает с заказом все, кроме управления кредитными лимитами и долгами, а как только возникает проблема с лимитом – к заказу подключается бухгалтер и добивается урегулирования этого вопроса.
Это – идеальная схема работы, но не пытайтесь реализовать её сразу! Скорее всего, для вас это будет очень сложно, так как чем меньше задействовано людей на первом этапе внедрения, тем лучше оно пойдет.
При этом верно и обратное утверждение: чем меньше людей задействовано во внедрении через год после его начала, тем хуже оно прошло. Поэтому грамотно распределяйте силы по дистанции, следуйте гайдлайнам из этого руководства, и, скорее всего, все будет хорошо.

В системе существует 3 роли пользователей агентства, которые отличаются ограничениями прав:

1. Рядовой сотрудник (агент)
   Может обрабатывать заказы, не имеет доступа к настройкам тревел менеджмента.
   Видит только заказы, которые назначены на него, и заказы, которые не имеют исполнителя;

2. Руководитель СТ
   Обладает правами сотрудника + видит все заказы в СТ и может передавать их другим исполнителям.
   Имеет доступ к кредитным линиям и отчетам по качеству;

3. Администратор
   Суперпользователь. Может все то, что руководитель СТ + имеет доступ к административным настройкам системы.
   Не давайте эту роль непроверенным людям.
   2-3 администратора в агентстве – норма, 20-30 – результат неправильного внедрения.

Рассмотрим примеры заведения пользователей в систему.
В качестве модели возьмем агентство, которое обслуживает корпоратов и субагентов. При этом субагентами занимается одна группа специалистов (СТ), а корпоратами – другая.

Пример 1: сотрудник дневной смены, который поддерживает корпоративных клиентов по авиа- и ж/д билетам:

Open

Чтобы пользователи получали меньше уведомлений по электронной почте, можно ограничить типы сообщений, которые они будут получать на email:

Пример 2: бухгалтер, который контролирует задолженности по корпоратам и субам:

Обратите внимание – так как бухгалтер не обрабатывает заказы (он не выпишет билет клиенту, ему не нужно знать про текущую операционную активность), то у него нет привязки к типам услуг, а только к задачам:

Для того, чтобы работать с кредитным лимитом, бухгалтер должен иметь роль «Руководитель СТ»

Пример 3: КАМ, который работает с корпоратами и следит за тем, чтобы их заказы обрабатывались корректно.