Отчеты: история статусов задач

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

История статусов задач ПланФикса

Что новенького?
В отчетах по объекту “Задача” появилась новая группа данных — “История статусов”:

Группа значений для вывода в столбцах отчета:
Давайте для начала сделаем простой отчет, в котором выведем эти данные по задаче и посмотрим, как это выглядит. Создаем новый отчет по объекту «Задача»:

Создание нового отчета по задачам в ПланФиксе
На вкладке “Вид отчета” добавляем столбец с названием задачи и все новые столбцы с историей статусов. В списке они расположены по алфавиту, но я их расположил в более удобном для просмотра данных порядке:

Отчет по истории статусов задач в ПланФиксе

(по клику картинка откроется в новой вкладке)

На вкладке “Параметры отбора” поставим какое-нибудь ограничивающее условие, а то по умолчанию получим историю всех задач за все время вашей работы в ПланФиксе — это может быть многовато для простого теста:

Параметры отбора данных в отчет по задачам ПланФикса
Запускаем отчет и получаем вот такую историю (для удобства привел результат по одной задаче):

История статусов задачи в ПланФиксе
Как видите, в отчете действительно отобразилась история по статусам, которые принимала эта задача. Мы видим статус и его порядковый номер в наборе, а также можем отследить время нахождения задачи в этом статусе(как общее, так и рабочее время исполнителя), в какой статус она потом перешла и когда это случилось.

Так как варианты использования этих данных могут быть не до конца очевидны, давайте рассмотрим пару примеров.

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

Например, если техподдержка работает с 9 утра, а клиент создал новый тикет в 8, то неправильно считать часовую просрочку, которая прошла с момента создания задачи до момента ее принятия — ведь исполнитель только что пришел на работу. А так анализируется только рабочее время исполнителя, и неважно, сколько задача провела в статусе “Новая” до начала рабочего дня или во время обеденного перерыва.

Статистика по этапам
Если сделать в отчете с данными истории статусов группировку по полю “История статусов. Статус”, то получится хорошая основа для различных статистических выборок, показывающих потенциальные проблемы в ходе осуществления бизнес-процесса.

Например, теперь мы добавили в стандартную конфигурацию “Управление сделками” два новых отчета: “Воронка продаж: анализ за период” и “Воронка срывов: анализ за период”. С их помощью вы можете:

  • смотреть, сколько времени (совокупно и в среднем) сделки находятся на каждом из этапов;
  • с каких этапов происходят срывы сделок — сколько сделок и на какую сумму сорвалось с каждого из этапов, сколько они (в общем и среднем) находились на этом этапе перед тем, как сорваться;
  • как меняются все эти данные со временем: выпуская отчет за любой период, можно отслеживать, как влияют на картину действия, предпринимаемые вами для расширения воронки продаж.

Описывать эти отчеты подробно я не буду, чтобы не утомлять тех, кому это не нужно — вы можете установить эту конфигурацию в своем аккаунте и посмотреть, как они устроены изнутри. (Если у вас уже установлена эта конфигурация, лучше создать новый аккаунт и попробовать обновленную конфигурацию в нем — учтите, что если вы удалите у себя конфигурацию, то пропадут данные, которые вы уже успели ввести. Ну или напишите нам в Службу поддержки, сделаем и пришлем вам скриншоты отчетов.)

Думаю, этих двух примеров применения истории статусов будет достаточно для того, чтобы составить представление о новых возможностях отчетов ПланФикса.

Короткой строкой упомяну еще об одном обновлении: теперь по контрагенту задачи можно вывести не только его название, но и другие реквизиты, включая созданные вами кастомные поля. Это может пригодиться в различных учетных кейсах, вроде “Добавить в карточку клиента процент скидки и использовать его при вычислении итоговой суммы к оплате”.

Дмитрий Гончаренко Команда ПланФикса

 

Перечисленные возможности доступны во всех аккаунтах ПланФикса, включая бесплатные — так что пробуйте, пишите о непонятностях и неудобствах. Продолжаем работать.

12 Comments

  1. теперь по контрагенту задачи можно вывести не только его название, но и другие реквизиты, включая созданные вами кастомные поля.

    Вот тут не совсем понял как это сделать.
    Есть Фирма/контрагент и у нее есть кастомное поле.
    надо его вытащить в задачу и в отчеты в использование формул.
    Отчеты по задаче строятся.

  2. Сделайте пожалуйста в отчетах (или в фильтре задач) поле «автор последнего действия».
    Если автор последнего действия — клиент и с момента посл.действия прошло 3 дня, а исполнители забили на задачу и не отвечают клиенту, то проверяющий должен это видеть и сделать атата. А сейчас контролировать работников техподдержки невозможно впринципе, т.к. каждый день проходить по всем тикетам (которых не мало) и смотреть в каждом их них — ответили или не ответили — это будет проще самому проверяющему отвечать.

    1. Дмитрий Гончаренко

      Ситуация понятна. Обсудим, там не просто это сделать — нужно реализовать спецхранение признака на уровне задачи и потом с ним работать.

      Достаточно знать, сотрудник это или контакт, я так понимаю — не обязательно хранить имя?

      1. Ну да, лично. У меня все сотрудники — это сотрудники, а все клиенты — это контакты. Поэтому мне подойдет такое разделение.

        Могу предположить что у кого-то в контактах есть фрилансеры… И они хотели бы делить на группы или что-то такое. Но мне кажется смысла в этом не много. Как правило контактом держат только временных фрилансеров. А если человек работает постоянно, то его переводят в сотрудники. А техподдержкой и общением с клиентами занимаются именно стабильные сотрудники.

      2. Вот например в HelpDesk системе ******* сделано чуть по другому — когда сотрудник отвечает на тикет, тикет переводится в статус «ожидание» или «Закрытый», а когда отвечает клиент — тикет автоматом становится «открытым» и можно отслеживать не по автору посл.действия а просто по статусу.

        Может быть имеет смысл сделать опцию «выставлять задаче статус «В работе» если приходит действие от контакта».
        Если это проще.

        (статус «ожидание» уж ладно можно заставить сотрудников руками ставить в момент ответа. Тем более это кастомный статус вообще)

Добавить комментарий