Заявки на бронювання: хто відповідає далі?
Призначте відповідальних, фіксуйте рішення й передавайте заявки між змінами та каналами зі зрозумілим порядком погодження.
Для кого цей посібник
Власники студій, команди прийому та служби обслуговування, які діляться запитами між змінами, каналами чи ролями затвердження.
Запит прочитали двоє людей, і кожен думає, що відповідає інший. Клієнт питає про бронювання, адміністратор чекає рішення керівника, а наступна зміна не знає, що вже пообіцяли. Спочатку це проблема відповідальності, а вже потім — швидкості відповіді. Під час передачі заявки слід указати відповідального, очікуване рішення й термін наступної дії. Просте правило: заявка залишається за однією людиною, доки інша явно не погодиться її прийняти.
Один відповідальний і одна наступна дія.
Спільна папка «Вхідні» робить розмову видимою; воно не вирішує, хто відповідальний. Призначте одну особу для переміщення кожного активного запиту вперед. Інші можуть робити внески, але поточний відповідальний перевіряє виконання наступної дії та інформує клієнта. Коли робота переходить з рук в руки, отримувач повинен підтвердити передачу, а не випадково відкривати старе повідомлення.
Запишіть достатньо контексту, щоб наступна особа могла працювати: клієнт і посилання на бронювання, запит, те, що вже було узгоджено, невиконане рішення, наступна дія та належний час. Тримайте факти окремо від припущень. «Клієнт подав запит на пізніший початок; очікується схвалення менеджера» є більш корисним, ніж «ймовірно добре». Не описуйте запитану зміну як підтверджену до того, як уповноважена особа погодиться.
Використовуйте прості робочі мітки, зрозумілі вашій команді, як-от очікування клієнта, очікування внутрішнього рішення, готовий підтвердити та закрито. Це приклади операційної угоди, а не заява про існування певного статусу програмного забезпечення. На етикетці має бути пояснено блокувальник; у полі відповідального має бути пояснено, хто відповідає за її вирішення.
Отримайте погодження, не перенаправляючи клієнта.
Деякі запити потребують повноважень, яких поточний відповідальний не має: зміна узгодженого обсягу, створення винятків щодо доступності або затвердження комерційних коригувань. Визначте, хто може приймати рішення та яка інформація потрібна цій особі. Ескалація рішення не повинна автоматично покладати на клієнта відповідальність за пошук того, хто схвалює. Поточний відповідальний може залишатися контактом клієнта, поки менеджер надає відповідь.
Корисна примітка про передачу може звучати так: "Клієнт просить перенести портретний сеанс у п’ятницю на довший проміжок часу. Поточний відповідальний: рецепція. Необхідне рішення: менеджер підтвердить тривалість і доступність. Наступна дія: рецепція надсилає узгоджені варіанти після схвалення. Перегляд до: четверга вдень". Це наочний приклад. Адаптуйте ролі та кінцевий термін до вашої фактичної служби та перевіряйте календар, перш ніж пропонувати зміну.
Погодьтеся, що станеться, якщо затверджувач відсутній або час перевірки мине. Назвіть резервну роль і пункт для повторного перегляду. Повідомте клієнта, коли ви плануєте його оновити, не обіцяючи результату, який ви не можете дозволити. Чіткий шлях ескалації корисніший, ніж кілька колег, які надсилають окремі повідомлення «ми перевіряємо».
“Передача завершена, коли наступний відповідальний знає рішення, наступну дію та час її виконання.”
Передайте наступній зміні контекст розмови.
Перед зміною зміни перегляньте відкриті запити відповідального та блокувальника. Для кожного перевірте, чи клієнт чекає вашу команду, чи ваша команда чекає клієнта. Включіть останнє значуще оновлення та будь-які вже взяті зобов’язання. Особа, яка приходить, повинна мати можливість пояснити наступний крок, не просячи клієнта повторити початковий запит.
Зберігайте те саме посилання, коли запит переходить із соціального повідомлення до електронної пошти чи запису бронювання. Запишіть рішення в контексті спільного клієнта, а не залишайте єдину відповідь у приватному чаті. Поділіться лише тими деталями, які потрібні для роботи, і дотримуйтеся існуючих прав доступу. Цей посібник стосується безперервності між людьми та каналами; посилання на бронювання певної послуги все ще може впоратися з простою частиною планування.
Наприкінці тижня перегляньте невелику вибірку невирішених передач. Шукайте відсутніх відповідальних, нечіткі повноваження затвердження, прострочені дії та запити, позначені як завершені до того, як клієнт отримав відповідь. Усуньте один повторюваний пропуск, перш ніж додавати інше сповіщення. Нагадування може привернути увагу до завдання, але воно не може вирішити, кому воно належить.
Передача, яку може прийняти інша особа
- Власник: назвіть поточний контакт і особу, яка приймає наступну дію.
- Рішення: записати запит клієнта, узгоджені факти, блокувальник і авторизований схвалювач.
- Контроль: установіть час перегляду, роль резервного копіювання та оновлення, яке має отримати клієнт.
Зробіть право відповідальності видимим, перш ніж додавати автоматизацію.
Використовуйте записи клієнта, щоб разом зберігати відповідний контекст бронювання, і домовтеся, як ваша команда записує відповідальність і наступні дії. Перевірте угоду за одним запитом, який перетинає зміну або потребує затвердження. Якщо особа, яка приймає, може продовжити розмову, не відновлюючи розмову, передача працює. Потім подумайте про нагадування щодо пунктів перевірки, які ви визначили, зберігаючи відповідальність перед вказаною особою.
Поширені запитання
Хто має володіти запитом на бронювання, якщо задіяно кілька співробітників?
Призначте одного поточного відповідального для координації наступних дій і оновлення клієнта. Інші співробітники можуть сприяти або затверджувати рішення. Передайте право відповідальності, коли особа, яка приймає, явно приймає передачу.
Що належить до запису про передачу бронювання?
Включіть довідку про клієнта або бронювання, запит, узгоджені факти, невирішене рішення, поточного відповідального, наступну дію, час перевірки та, якщо потрібно, особу, яка затверджує. Відрізняйте припущення від підтверджених змін.
Коли потрібно передати запит на бронювання?
Передайте рішення, коли для рішення потрібні повноваження, яких бракує поточному відповідальнийу, минув час на перевірку або звичайний затверджувач недоступний. Визначте резервну роль, зберігаючи для клієнта один чіткий контакт.