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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

Один комментарий

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

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

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

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

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

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

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

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

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

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

  6. Отличная функция. Не хватает только даты перехода в сам статус и возможности фильтрации по дате. Сейчас есть только дата перехода в следующий статус и возможность установки фильтра по равенству и неравенству. Пример: Нужен отчет по процессу найма сотрудников сколько пришло сколько принято за этот месяц. И если дату перехода в статус можно вычислить формулой “Дата перехода в следующий” минус “время в статусе”, то отфильтровать по периоду возможности нет.

    1. Там можно поиграть с формулами и сделать вывод месяца, в котором задача вошла или вышла в нужный статус. А потом по этому столбцу с месяцем сделать фильтр. Если не получится самостоятельно, напишите в Службу поддержки, коллеги помогут.

    1. Да, получился отличный “тайм-трекинг для ленивых”: ничего отмечать не нужно, просто переводим статус задачи и получаем готовый биллинг по проекту клиента 🙂

  8. Есть вопросы. Такая ситуация. Задача в статусе “В работе”. Работали над ней каждый день по часу-два. В один из дней забыли перекинуть задачу в слудющий статус. В результате в отчете написано +-20часов сверху.

    1) Возможно ли отредактировать поле “Дата перевода в следующий статус” по данной задаче и определенный переход в статус “В работе”?
    2) Возможно ли настроить автоматическую смену задачи из одного статуса в другой через определенный промежуток времени?

        1. Рад помочь)

          А вот по первому нет идей кроме озвученной корректировки. Для разового случая это проще всего.

          Если бы такие промахи случались постоянно, может быть имело бы смысл ввести на уровень задачи поле вроде “Билингуемые часы”, чтобы иметь возможность вручную вносить туда время для таких ситуаций. Соответственно, в отчете тоже вывести это поле и итог по задаче формировать по условию “Если есть значение в “Билингуемых часах”, то ставим его, а если нет – то время из истории статусов”.

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