AI-Support: Контроль сроков

    Вычисление "Рабочих часов" (исключение выходных) в скриптах n8n.

1. Управленческая задача: Точный расчет SLA и справедливое измерение производительности.
Вычисление "Рабочих часов" (Business Hours calculation) в скриптах n8n, с исключением выходных и праздничных дней, — это фундаментальный элемент для точного контроля SLA (Service Level Agreement — соглашение об уровне сервиса) и объективной оценки производительности службы поддержки. Без этой логики, SLA-таймеры будут "тикать" круглосуточно, включая нерабочее время, что приведет к ложным просрочкам, несправедливым штрафам и демотивации сотрудников. Цель — гарантировать, что все временные метрики (TTR, TTRS, время эскалации) рассчитываются только за то время, когда служба поддержки фактически работает, обеспечивая прозрачность и точность в отношениях с клиентами и внутри команды.

2. Суть проблемы и её решение.

• Проблема: Клиент отправляет заявку в пятницу вечером. SLA на ответ 4 часа. Если система считает 24/7, то к полуночи субботы SLA будет нарушено, хотя сотрудники не работают.
• Решение: n8n должен учитывать рабочие календари вашей компании и календари обслуживания клиента.
  • Рабочий календарь: Определяет стандартные рабочие часы (например, с 9:00 до 18:00) и нерабочие дни (суббота, воскресенье, государственные праздники).
  • Календарь обслуживания клиента: Может отличаться (например, у премиум-клиентов может быть 24/7, у стандартных — 8/5).

3. Реализация в n8n.
n8n использует JavaScript-коды (Java Script — язык программирования) или специализированные ноды (блоки) для работы с датами и временем.

1. Исходные данные:
   • StartTime (Время создания тикета).
   • DeadlineTime (Время, до которого нужно решить/ответить по SLA).
   • WorkingHoursStart (например, 9:00).
   • WorkingHoursEnd (например, 18:00).
   • Список Holidays (Массив дат праздничных дней).
   • SLA_Type (например, "8x5", "24x7").
2. Логика вычисления:
   • Для SLA_Type = "24x7": Вычисление простое — DeadlineTime = StartTime + SLA-норматив. Выходные не исключаются.
   • Для SLA_Type = "8x5":
     • Итерация по дням: Скрипт в n8n начинает с StartTime и итерирует (перебирает) день за днем до DeadlineTime.
     • Исключение выходных: На каждом шаге проверяется, является ли текущий день субботой или воскресеньем. Если да, он пропускается.
     • Исключение праздников: Проверяется, есть ли текущий день в списке Holidays. Если да, он пропускается.
     • Учет рабочих часов в дне: Если день рабочий:
       • Если StartTime попадает в нерабочее время (например, заявка пришла в 20:00 в пятницу), отсчет начинается с начала следующего рабочего дня (например, 9:00 понедельника).
       • От каждого рабочего дня отнимается нерабочее время (с 18:00 до 9:00 следующего дня).
       • Считаются только часы, попадающие в WorkingHoursStart и WorkingHoursEnd.
     • Остаток времени: Скрипт отсчитывает "чистые" рабочие часы до тех пор, пока не будет достигнут норматив SLA.
3. Результат: n8n вычисляет точное время SLA_Deadline и записывает его в Vtiger.

4. Поддержка и настройка.

• Список праздников: Должен регулярно обновляться (можно использовать API государственных праздников).
• Vtiger: Поле "Время дедлайна SLA" должно быть в Vtiger для каждого тикета.

5. Управленческие выгоды.

• Точный контроль SLA: Гарантия выполнения обязательств перед клиентами.
• Справедливая оценка: Объективное измерение производительности команды, без ложных просрочек.
• Прозрачность для клиента: Клиент понимает, что SLA учитывает только рабочее время.
• Снижение штрафов: Минимизация финансовых потерь из-за неправильного расчета.
• Улучшение планирования: Более точные прогнозы по времени решения задач.
• Мотивация команды: Сотрудники видят, что их работа оценивается справедливо.

   Триггеры "За 1 час до просрочки".

1. Управленческая задача: Проактивное управление SLA и предотвращение нарушений.
Внедрение триггеров "За 1 час до просрочки" — это критически важный механизм проактивного управления SLA (Service Level Agreement — соглашение об уровне сервиса). Цель — не просто фиксировать факт нарушения SLA, а предупреждать о нем заранее, давая менеджерам и инженерам время для принятия корректирующих действий. Это позволяет избежать штрафов, сохранить репутацию, повысить уровень удовлетворенности клиентов и снизить количество "красных" тикетов в системе.

2. Механизм работы триггеров.

• Основа: Точное вычисление SLA_Deadline (времени, до которого нужно решить/ответить) для каждого тикета, с учетом рабочих часов и календарей. Эта дата рассчитывается n8n при создании тикета.
• n8n как монитор: n8n настраивается на периодическую проверку (например, каждые 15-30 минут) всех активных тикетов в Vtiger.
• Условие срабатывания: n8n проверяет: Текущее время >= (SLA_Deadline - 1 час) И Текущее время < SLA_Deadline И Тикет.Статус != "Решено" / "Закрыто".
• Действие при срабатывании: Если условие выполнено, n8n немедленно инициирует серию уведомлений и, возможно, действий:
  • Уведомление ответственному инженеру (L2/L3): Push-уведомление в Telegram, Email, SMS (для P1). Текст: "Внимание! Тикет #[Ticket ID] по клиенту [Client Name] будет просрочен через 1 час! Тема: [Ticket Subject]."
  • Уведомление руководителю L2/Team Lead: Аналогичное уведомление с пометкой о критичности.
  • Изменение цвета/статуса в Vtiger/OpenProject: n8n может обновить кастомное поле или статус тикета/задачи в Vtiger/OpenProject, чтобы он начал мигать красным цветом или перешел в статус "Критическое ожидание", привлекая внимание.
  • Повышение приоритета (опционально): Для особо критичных тикетов n8n может временно повысить их внутренний приоритет, чтобы они отображались выше в списках задач.

3. Гибкость настройки.

• Время предупреждения: "1 час до просрочки" — это пример. Для P1 может быть 30 минут, для P4 — 4 часа. Это настраивается в n8n в зависимости от типа тикета и его приоритета.
• Каналы уведомлений: Разные каналы для разных уровней критичности. Для P1 — SMS и звонок (через FreePBX API), для P3 — Email.
• Дерево эскалации: Эти триггеры могут быть частью общего дерева эскалации, где за "1 час до" следует "наступила просрочка".

4. Поддержка и мониторинг.

• Дашборды: Vtiger и OpenProject должны отображать тикеты, по которым скоро наступит просрочка, на специальных дашбордах "На грани SLA".
• Отчеты: Аналитика по количеству "предупреждений" и их отношению к реальным просрочкам.

5. Управленческие выгоды.

• Предотвращение нарушений SLA: Возможность своевременно вмешаться и решить проблему.
• Повышение удовлетворенности клиентов: Клиенты реже сталкиваются с просрочками.
• Снижение финансовых рисков: Избежание штрафов, предусмотренных в SLA-контрактах.
• Проактивное управление: Переход от реагирования на проблемы к их предотвращению.
• Мотивация команды: Инженеры получают четкий сигнал и могут скорректировать свою работу.
• Прозрачность: Руководители видят потенциальные проблемы заранее.
• Улучшение репутации: Надежная и ответственная служба поддержки.