Перейти до змісту

Автоматичні завдання

Налаштування, яке позбавляє сервіс ручної роботи: щойно сервісне замовлення переходить у новий стан, система сама створює завдання потрібним співробітникам.

Де шукати: Модулі → CRM → Налаштування → Автоматичні завдання

Розбір на прикладі

Автоматичні завдання

Угорі — тип сповіщення («Сповіщення») для завдань із блоків: «Ні», повідомлення в системі, СМС, e-mail або Telegram. Нижче, на вкладці «Стор. 1», — блоки, і кожен блок відповідає одному стану сервісного замовлення: «В очікуванні», «На діагностиці», «На узгодженні», «Клієнт думає», «Узгоджено», «В ремонті». Вкладка «Стор. 2» продовжує перелік: «У віддал. сервісі», «Замов. деталі», «Очік. на деталі», «Готове», «Поверн. на доопрац.» і «Відмова» — так само підписані й стани в самому замовленні.

У кожному блоці три поля:

Поле Що задає
Співробітники Логіни через кому — вони стануть виконавцями задачі
Опис Текст, який потрапить в опис задачі: що саме треба зробити
Тип Тип завдання, яким позначиться задача

У прикладі заповнені чотири стани: приймання заявки й діагностику веде ІНЖЕНЕР, погодження вартості — SA, ремонт знову ІНЖЕНЕР.

Як це працює

  1. Менеджер змінює стан сервісного замовлення.
  2. Система бере блок цього стану і створює завдання з назвою «Замовл. на обслуг. № …», описом і типом із блоку; відкрите завдання попереднього стану цього замовлення при цьому закривається.
  3. Виконавцями стають перелічені співробітники, і кожен отримує сповіщення обраним способом.

Блок без співробітників або без типу завдання не створює й нічого не закриває. Окремо від налаштування при кожній зміні стану система ставить завдання відповідальному (поле «Відповідальний» замовлення) або заново відкриває попереднє таке — якщо в типах завдань є тип із кодом цього стану. Це завдання не залежить від блоків і від типу сповіщення вгорі: воно завжди сповіщає повідомленням у системі. У стартовій базі такі типи заведені для всіх дванадцяти станів.

Три стани працюють ще й із клієнтом, якщо в замовленні вказано телефон (без нього не йде нічого): коли замовлення переходить «На діагностиці» (повідомлення, що його прийняли), стає готовим або отримує відмову, клієнту йде СМС за шаблоном із текстів повідомлень, якщо відправку СМС там увімкнено. Контакт, підключений до бота Telegram, замість СМС отримує коротке повідомлення в Telegram — і тоді, коли відправку СМС вимкнено. Замовлення, створене одразу в стані «На діагностиці», повідомлення не отримує; створене одразу готовим чи з відмовою — отримує.

Типові ситуації

Завдання не створюються. Перевірте, чи заповнений блок потрібного стану: без співробітників або без типу задачі не буде.

Замовлення не переходить у новий стан: «Тип дії «…» не існує». У блоці цього стану вказано тип, якого немає в типах завдань, і система не зберігає саме замовлення. Виправте тип у блоці або заведіть його в типах завдань.

Налаштування не зберігається: «Користувач «…» не заведений». Один із логінів списку не існує або набраний з помилкою — відмова називає саме його. Закритого користувача налаштування теж не прийме: «Користувач «…» закритий». Пробіли після коми можна лишати.

Задачі створюються, але ніхто про них не знає. У співробітників не заповнені контакти для обраного каналу — або вгорі вибрано «Ні»: тоді задачі блоків створюються зі знятою галочкою «Сповіщення», і їхнім виконавцям повідомлень немає зовсім (так задумано; до 10.10.2026 «Ні» помилково працювало як повідомлення в системі). Завдання відповідальному вибір «Ні» не вимикає.

Потрібно, щоб на різних станах працювали різні люди. Так і задумано: кожен блок незалежний, у ньому свій перелік співробітників.