Подробное описание попытки создать продвинутое управление заявками и сделками

[Константин Смоквин]

Здравствуйте!
Это не совсем удачный опыт использования, но думаю будет полезно описать его. Возможно, кто-то из опытных пользователей подскажет пути решения или описанное послужит вдохновением для разработчиков - курсивом выделены фрагменты, где не хватает кое-каких тонкостей в возможностях Планфикса.

Извините за очень много букв. У меня по другому не выходит.

Цель: создать удобный интерфейс для обработки входящих заявок, превращения заявок в заказы и контроля, организации работы и общего контроля заказов.

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

Проблемы на этом этапе состоят в том, что:

А) Непонятно, какая заявка на каком этапе находится. Это уже предварительное обсуждение? Или уже заказ? Если заказ, то на каком этапе мы находимся? Как быстро понять, что происходит?

С этой проблемой успешно справится набор статусов. Создаём отдельный процесс "Заказ" с уникальным набором статусов от "Обсуждение заявки" до "Успешное завершение заказа" включая кучу промежуточных стадий. Делаем все входящие в проект "Отдел продаж" задачи автоматически с этим процессом и стартовым статусом "Обсуждение заявки". Идеально.


Б) В большинстве случаев общение с заказчиком происходит прямо в этой самой задаче (изначальной заявке). Но помимо общения с заказчиком ещё есть нужда сотрудников комментировать происходящее по заказу\заявке в режиме реального времени и эти комментарии не должен видеть клиент!

Тут уже непонятно как это решить простым способом. Общаться всё время с использованием "скрытого замком" комментария очень неудобно. То ошибёшься и отправишь случайно публичный комментарий и его увидит клиент. То не заметишь "замок" другого сотрудника и публично прокомментируешь его комментарий и это увидит клиент. Ещё проблема, что нужно чтобы твой скрытый комментарий видели ВСЕ сотрудники, но не клиент. То есть оповестить о скрытом комментарии приходится всех, даже тех кто не на смене сейчас - в итоге они получают три тонн лишних оповещений в свои нерабочие дни. А не оповещать их - они не смогут увидеть скрытые комментарии, когда заступят на смену. Да, и превращается это всё в кашу из публичного обсуждения с клиентом и внутреннего обсуждения сотрудников.

Здесь чувствуется острая необходимость вынесения приватного обсуждения сотрудников в отдельную задачу. Возможно так и нужно поступать. На каждую входящую заявку - создавать отдельную задачу-обсуждение заявки. В итоге у нас получается на 1 заявку  - 2 задачи. И набор новых проблем:


В) Какая из двух задач главная? Они не могут обе быть с процессом "Заказ" с необходимостью постоянно контролировать и синхронизировать их статус согласно этапу работ. И даже если синхронизировать статусы автоматически сценариями, то всё равно у нас тогда получается 2 задачи-заказа на 1 реальный заказ, что очевидно плохо для планировщика, сводок, отчётов. Очевидно, что какая то одна задача должна остаться с процессом "Заказ" и в ней должен контролироваться общий процесс заявки\заказа, а вторая задача должна стать Стандартной задачей со стандартным набором статусов. 

Тут у нас есть следующие варианты:

В1) Сделать главной задачей контроля заказа ту задачу, где клиент изначально обратился. А задачу внутреннего обсуждения сотрудников сделать обычной стандартной задачей. С точки зрения реализации здесь всё просто. Пришла заявка - сценарием создаём подзадачу по стандартному шаблону со стандартным процессом. Не руками же её создавать каждый раз?

Но на практике это выходит неудобно по следующим причинам:
- рутинные задачи этого заказа мы тоже прикрепляем подзаказом к основной задаче-заявке клиента и в итоге задача-внутреннее-обсуждение "теряться" среди них - относительно долго искать для того, чтобы оставить комментарий другим сотрудникам о происходящем.
- комментарии сотрудников по заказу, отчёты по происходящему и прочие заметки, которые дают быстро понять, что происходит в заказе у нас в одной задаче. А общий статус закака "Ожидаем предоплату \ Установка \ Доводка \ ...." у нас в другой задаче. Это совсем неудобно.
- и редкий случай, но очень проблемная ситуация: заказ дошёл до финальной стадии и помечен статусом "Заказ успешно завершён". Это неактивный статус - чтобы задача пропала из списка активных задач и не мешалась ежедневной работе. Но не забываем, что задачей по контролю статуса заказа мы сделали задачу в которой ВЕДЁМ ОБСУЖДЕНИЕ С КЛИЕНТОМ. Иногда заказ уже давно завершён, но клиент возвращается. И нет - он не напишет на сайте новую заявку через форму. Ему удобнее ответить на последнее наше письмо. И его комментарий попадёт в эту задачу со статусом "Заказ успешно завершён". Что делать???
---- Можно было бы сценарием открывать задачу в активный статус, когда пришло сообщение от клиента (мы так делаем со стандартными задачами) - но тут это не подойдёт: заказ же закрыт? Делать его активным - нарушит отображение статистики по закрытым заказам.
---- Оставлять его закрытым? Но тогда непонятно где задача - и кто ответственен за продолжение диалога с клиентом. Да, на основе поступившего комментариях дежурный менеджер может вручную создать новую задачу, оставив задачу-заказ закрытой. Но один неосторожный жест в хронике - случайно снятое оповещение про новый комментарий - и всё, сообщение клиента навсегда погребено в завершённой неактивной задаче, про него больше никто не вспомнит.
---- Как вариант здесь было бы идеально создавать сценарием новую подзадачу на основе этого комментария. Сейчас в сценариях есть возможность создать подзадачу - но текст комментария сценарием туда никак не перенести и проблемы с заголовком. Создание подзадачи по шаблону не предусматривает заголовок как у надзадачи или "как у надазадачи + модификация". Тема с изменением заголовков сценариями очень обширная и МНОГО где полезно было бы это свойство в сценариях. Но главная проблема это действительно то, что нельзя создать новую задачу на основе нового комментария. Желательно с удалением комментария из изначальной задачи, чтобы не было путаницы.

Этот набор проблем указывает на то, что вариант 1 (В1) - это совсем не вариант. Нужно поступать иначе:


В2) Альтернативный вариант - это при двух задачах на заказ сделать главной не ту, где заявка и присутствует клиент в ней для обсуждения, а ту вторую, где идёт приватное обсуждение заказа сотрудниками. Удобно с точки зрения контроля - статус заявки и комментарии сотрудников в одном месте. Но с точки зрения автоматизации процесса - проблема. 

Интуитивно я ожидаю, что главная задача заказа, в которой указан статус всего заказа и описаны нюансы заказа - будет надзадачей всех остальных задач - задачи заявки-обсуждения с клиентом и прочих дополнительных задач рутины. То есть при получении новой задачи-заявки оставляем её со стандартным процессом, а нужно создать новую задачу-заказ с процессом Заказ и сделать эту задачу НАДЗАДАЧЕЙ к заявке, что было бы логично. Но Планфикс, к сожалению, пока не умеет создавать НАДЗАДАЧИ сценариями, только подзадачи. (Лирическое отступление: ручное создание надзадачи мы не рассматриваем, мы же стараемся сделать систему с максимальным устранением повторяющихся типовых действий). То есть в этом случае остаётся или делать задачу-заказ подзадачей заявки или делать её параллельной несвязанной задачей. Второй сразу отметается - собирать иерархическую связь задач вручную не вариант. А первый вариант с подзадачей - нарушает интуитивную логику. Возможно, у кого в рамках одного заказчика обычно много заказов, а не один, тогда это было бы удобно - прикреплять к одной заявке-обсуждению много разных заказов. Но у нас прямо зависания выходят когда у нас выходит дерево в котором надзадача - это рядовое обсуждение с клиентом, а подзадачами на одном уровне -задача общий контроль заказа вперемешку с рутинными задачами по выполнению этапов заказа.


В3) Исходя из того, что оба описанных выше варианта проблемные, на этом этапе мы решили отказаться от идеи создания второй задачи, а оставить таки одну задачу и делать задачу-заказ с уникальным процессом и статусами на основе единственной задачи-заявки. В итоге у нас остаётся проблема, что делать если заказ завершён, а клиент написал новое сообщение - и продолжаем страдать со скрытыми комментариями между сотрудниками внутри общего обсуждения с клиентом.. Звучит ещё хуже чем вариант 2, но на практике лично для нас пока это ЧУТЬ менее неудобно чем второй вариант. Но всё равно это не решение.

----------------
Этап 2. Меняем подход.

Так как с этим нужно что-то делать, решили двигаться дальше в следующем направлении. Убираем уникальный процесс с уникальными статусами (как бы не казалось, что процесс и статусы должны идеально решать задачу - этого не получилось). Создаём кастомное поле с этим же псевдо-статусами - "Статус заказа". Создаём отдельный шаблон "Заказ" и добавляем в него это кастомное поле. Делаем чтобы все входящие в отдел продаж создавались по шаблону заказ.

На выходе получаем задачу, в которой можно контролировать статус выполнения заказа отдельно. И контролировать общую активность задачи отдельно от статуса заказа. То есть если в завершённый заказ нам снова напишет клиент - мы спокойно сценарием возвращаем этой задаче стандартный статус "В работе" - и это никак не повлияет на отчёты и статистику, ведь они будут учитывать значение кастомного поля, а не статуса задачи.

Как это всё будет работать и с какими трудностями столкнёмся в процессе пока непонятно - только на днях планируем начать перестраивать систему соответственно. Но пока выглядит удачнее первого захода. Жаль только не удалось решить проблему так, как по идее она должна была быть решена по задумке Планфикса.

---------------

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

Ещё выше было упомянуто про заголовки. Не подробно. Но на практике здесь и в других местах очень и очень не хватает возможности редактировать заголовок задачи сценарием. Что-то вроде:
- Установить произвольный заголовок
- Установить заголовок равный надзадаче
- Равный надазадаче + префикс \ суффикс
- Добавить к текущему заголовку префикс \ суффикс
- Вырезать из заголовка подстроку

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

------------------

PS. Это не критика Планфикса. Я люблю Планфикс. Я люблю Планфикс сильнее гугла, букмейта и пятнадцати других идеальных сервисов, самоидентификация с которыми делает меня мной! )) Я восторге от того, как Планфикс продуман и как казалось бы сложные вещи не то что не нужно продумывать здесь, а они сами собой выстраиваются по ходу работы чисто на интуитивном уровне. Это восторг и текущая слюна! Но прошедшая неделя в попытках решения вышеописанных проблем привела к необходимости описать наш опыт на публику. Поэтому написано из любви, а не критики для.

[Виктор Зайцев]

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

Б) Проблему с общением предлагаю решить так: сделать подзадачу к основной задаче-заказу "Внутреннее обсуждение" в шаблоне которой задать права таким образом, чтобы клиент эту подзадачу не видел совсем. В настройках поставить, чтобы подзадачи отображались в виде чек-листа, тогда обсуждение всегда будет находиться под рукой, в основной задаче. 

Проблема В) отпадает, т.к. главной всегда будет задача-заказ. Для гарантии чтобы обсуждение нигде в отчетах не выскакивало и не портило статистику, можно ей в шаблоне прописать отдельный статус, например "обсуждение"

В1) Тут непонятно. Всё таки вы используете подзадачи или нет? По тексту вроде "да". Тогда:
- чтоб подзадача с обсуждением не терялась, выведите в виде чек-листа и настройте ручной сортировкой чтобы она всегда в самом верху была, так время на поиск сократится практически до нуля.
- то что комментарии в разных задачах, да тут немного неудобно, но это следствие требования к приватности. тут могу уж совсем экзотические методы предложить:
1) Использовать 2 монитора для вывода сразу двух задач в одном зрительном поле.
2) (бюджетный вариант 1)) Использовать браузер, который умеет делить экран на две вертикальные области и отображать там разные вкладки
3) (не знаю можно ли это реализовать?).  вывести все комментарии к основной задаче и к подзадаче,  с помощью какого-нибудь отчета, чтобы там их разом проанализировать. 
- комментарий в закрытый заказ. Вариант такой:
Сценарием создаём новую подзадачу с назначением на ответственное лицо (старый исполнитель или отдельный человек по работе с фидбэком например). В тексте подзадачи пишем что то вроде: "Внимание! Поступило обращение от клиента по закрытому заказу. Требуется реакция менеджера" ВСЁ! самая главная проблема решена - теперь обращение клиента никуда не сгинет, а будет обработано. Исполнителю остается разобраться, новый это заказ или доработка по старой заявке, скопировать ручками комментарий, выставить нужный статус и запустить заявку по стандартному процессу.  После того, как в ПФ добавят нужные условия по сценариям, данный сценарий просто редактируете и ищите дальше, что ещё бы автоматизировать =)

Если всё перечисленное вам не помогло и вы таки вернулись к варианту одна задача, можно ещё помозговать как правильнее реализовать, но нужно более подробное ТЗ. Могу попробовать помочь, мне интересно поразбираться, т.к. тоже сейчас находимся в стадии перехода на ПФ и соответственно перевода тех. процессов в данную систему.