Привязка канала связи через Мессенджеры в контакте а не задачи

[Виктор Черкашин]

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

Все это делает крайне тяжелым использование интеграции с мессенджерами.

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

[Dmitry Goncharenko]

Это предложение встречается достаточно часто. Тем не менее, мы считаем такой подход неправильным. Попробую объяснить почему.

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

Но если мы поставим себя на место клиента, то все будет выглядеть совершенно иначе.

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

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

- В Задаче 1, которая называется "Ананасы-Бананасы" менеджер пишет клиенту: "Груз отправлен, накладная №4598, газель 4456ЕЕ, встречайте"
- В Задаче 2, которая называется "Отгрузка апельсинов бочками" другой менеджер примерно в это же время пишет: "Иван Иваныч, к сожалению отгрузки на этой неделе не будет, подводят поставщики тары. Сообщу Вам, как только все будет готово".

Оба менеджера все написали правильно - они четко понимают контекст задачи, видят историю переписки по ней (и не видят переписки по задаче своего коллеги) и пишут сообщения клиенту исходя из этого контекста. А у клиента в мессенджере при этом каша, которая усиливается еще и тем, что оба сообщения могут приходить от одного и того же имени "Компания "Фрукт-Продукт" (зависит от возможностей конкретного мессенджера и настроек интеграции).

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

Именно поэтому мы осознанно ввели на стороне ПланФикса ограничение для подобных "моно"-каналов вроде мессенджеров и делаем для них такую же "моно"-задачу: это гарантирует, что вы всегда будет видеть то, что видит клиент и действовать в общем контексте с ним. Менеджер по бананасам напишет "Иван Иваныч, по вопросу бананасов - груз отправлен, накладная №4598, газель 4456ЕЕ, встречайте". Менеджер по апельсинам тоже будет более конкретен: "Иван Иваныч, к сожалению отгрузки апельсинов на этой неделе не будет, подводят поставщики тары. Сообщу Вам, как только все будет готово".

Вроде бы, всего пара слов, но какая разница в результате.

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

В общем, несмотря на такие вроде бы очевидные плюсы привязки каналов связи к клиентам, в реальности получаются сплошные минусы.

[Виктор Черкашин]

Добрый день.
Спасибо за развернутый ответ.

Код: Выделить всё

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

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


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

[Илья Федоров]

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

+

[Dmitry Goncharenko]

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

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

Да, именно так: на клиента это никак не влияет - и не может влиять, ведь он сидит в мессенджере, а не в ПланФиксе. А влияет только на оператора в ПланФиксе, который вынужден соблюдать контекст общения с клиентом, так как заходит в задачу-переписку с ним и видит весь контекст общения. Что вопросов несколько. Что перед ответом нужно уточнить, на какой именно вопрос он отвечает. И вот это принципиально влияет на то, понимают клиент с менеджером друг друга или нет.

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


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

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

С этим согласен, поставлю задачу, обсудим с коллегами.

[Виктор Черкашин]

Код: Выделить всё

Да, именно так: на клиента это никак не влияет

Тогда какие доводы против того чтобы сделать возможным:
- Создания сообщения клиенту из новой задачи, а не из старой которая была создана клиентом обращением из менеджера
- Писать в одной задаче нескольким клиентам в мессенджер
- Писать из одной задачи клиенту по разным каналам (так у нас общение через менеджер, а файлы нужно отсылать на почту)
?
Ранее речь шла о том, что это будет плохо для клиента. Сейчас как понимаю мы пришли к пониманию что для клиента ничего не поменяется, что сейчас, что в ситуации когда все это будет возможно.

Код: Выделить всё

Если Вы все же идете по пути разделения вопросов, поднятых клиентов, по отдельным задачам, то я бы рекомендовал делать их подзадачами к задаче-общению с клиентом

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

[Dmitry Goncharenko]

Тогда какие доводы против того чтобы сделать возможным:
- Создания сообщения клиенту из новой задачи, а не из старой которая была создана клиентом обращением из менеджера
- Писать в одной задаче нескольким клиентам в мессенджер
- Писать из одной задачи клиенту по разным каналам (так у нас общение через менеджер, а файлы нужно отсылать на почту)
?
Ранее речь шла о том, что это будет плохо для клиента. Сейчас как понимаю мы пришли к пониманию что для клиента ничего не поменяется, что сейчас, что в ситуации когда все это будет возможно.

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

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

Соответственно, клиент, получив в мессенджере подряд 2 сообщения "Ничего не приедет" и "Все отгрузили" не поймет, к какому вопросу какая фраза относится - да и вообще потеряется. Вот именно это для него и изменится, если сделать так, как Вы предлагаете. И так как это очень важный момент, мы сознательно не делаем такого разделения.

[Dmitry Goncharenko]

Основное почему мы не можем использовать единую задачу - проблема с уведомлениями

А как Вы в принципе видите работу с уведомлениями по, условно, 3 параллельно обсуждаемым вопросам? Клиент написал в мессенджере "Да, согласен" - куда должен попасть его ответ, в какую из 3-х задач?

[Виктор Черкашин]

Добрый день.
Спасибо за разъяснения.

>>Вот именно это для него и изменится, если сделать так, как Вы предлагаете. И так как это очень важный момент, мы сознательно не делаем такого разделения.

Т.е. Ваш отказ в изменении работы с мессенджерами связан с тем, что Вы предполагаете, что если писать менеджеры будут в едином чате, то они будут смотреть на историю переписки и писать будут так чтобы было понятно о чем речь, а если каждый в своей задаче, то будут писать кратко, так чтобы было непонятно о какой задаче речь.
Мнение тут субъективное и Вас и у меня, так что обсуждать и приводить аргументы бесполезно.

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

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

>>А как Вы в принципе видите работу с уведомлениями по, условно, 3 параллельно обсуждаемым вопросам? Клиент написал в мессенджере "Да, согласен" - куда должен попасть >>его ответ, в какую из 3-х задач?

Уведомления в случае использование единого чата или нескольких чатов? Нескольких чатов не будет, поэтому и обсуждать тут нечего.
Если говорить об уведомлении в едином чате, то.
1. Общение при наличии отрытых задач по контакту (где контакт участник).
Уведомление должно приходить всем исполнителям по открытым задачам
Т.е. в задаче-чате исполнители должны ставится автоматически при открытии задачи. При этом остальные исполнители убираются пока есть хотя бы одна активная задача (уведомления будет получать исполнитель задачи)
2. При закрытии задачи в задаче-чате исполнитель должен убраться (если нет других задач того же исполнителя с тем же контактом). Что этот оператор больше не получал уведомлений о сообщениях контакта
3. При закрытии всех задач по контакту в задаче-чате должен меняться статус на новая и снова исполнителями должны стать те, кто должны получать уведомления о новых задачах.
Таким образом не будут теряться новые заявки и будут уведомления о текущих заявках только тем, кто в них участвует.

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

Согласны с тем, что все это сильно облегчит работу операторов и при этом никак не ухудшит общение с клиентом?

[Dmitry Goncharenko]

Тогда пожелание следующее.
Сделать возможным привязку нескольких надзадач к задаче. Чтобы общение по одной задаче могло идти с несколькими контактами в удобном режиме.

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

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

Тут хотелось бы конкретики: как именно Вы видите такое добавление и чего для него сейчас не хватает.

[quote

]>>А как Вы в принципе видите работу с уведомлениями по, условно, 3 параллельно обсуждаемым вопросам? Клиент написал в мессенджере "Да, согласен" - куда должен попасть >>его ответ, в какую из 3-х задач?

Если говорить об уведомлении в едином чате, то.
1. Общение при наличии отрытых задач по контакту (где контакт участник).
Уведомление должно приходить всем исполнителям по открытым задачам

...

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

Согласны с тем, что все это сильно облегчит работу операторов и при этом никак не ухудшит общение с клиентом?
[/quote]

Не согласен, Виктор. И предполагаю, что не только я.

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

[Артем Никитенко]

Тоже сталкивался с такой проблемой.
Пока юзаю задачи чаты и раскидываю комментарии, не очень удобно.
У меня есть 2 идеи
1. Раз связь по одному каналу хранится для одной задачи, почему бы не позволить нам управлять этим?
Например у контакта дать возможность выбирать задачу по каждому каналу и в сценария добавить возможность менять.
Это сразу позволит решить множество проблем и добавит вариативности.
Например можно будет по ключевлму слову раскидыаать комментарии.
Да, будет риск потерять комментарий (не уследить куда улетел), но это уже дело рук того кто настраивал.
2. В сценраиях позволить менять не только над задачи или под задачи или в одном проекте, но вообще любую или ещё лучше брать из кастомного поля.
Т. К. В моем случае, задачи по клиенту в разных проектах и имеют свои надзадачи. Т. Е. Задачу-чат к ним не приставать, что бы например сценарием дублировать туда действия.
Данный вариант пригодится не только в таких случаях, т.к. сейчас по сути в сценарии, нельзя изменить задачу из другого проекта. Не очень хорошее ограничение.

[Виктор Черкашин]

Код: Выделить всё

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

Ну можно и не надзадачи.
Проще дополнительное поле - набор задач и чтобы тут автоматом заполнялись задачи-чаты участников текущей задачи.

Код: Выделить всё

Тут хотелось бы конкретики: как именно Вы видите такое добавление и чего для него сейчас не хватает.

Как устанавливать исполнителя в задаче-чат исходя из открытых задач по этому контакту?

Если развернуто то писал выше:
1. Общение при наличии отрытых задач по контакту (где контакт участник).
Уведомление должно приходить всем исполнителям по открытым задачам
Т.е. в задаче-чате исполнители должны ставится автоматически при открытии задачи. При этом остальные исполнители убираются пока есть хотя бы одна активная задача (уведомления будет получать исполнитель задачи)
2. При закрытии задачи в задаче-чате исполнитель должен убраться (если нет других задач того же исполнителя с тем же контактом). Что этот оператор больше не получал уведомлений о сообщениях контакта
3. При закрытии всех задач по контакту в задаче-чате должен меняться статус на новая и снова исполнителями должны стать те, кто должны получать уведомления о новых задачах.

Код: Выделить всё

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

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

[Артем Никитенко]

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

[А.А. Сахоненко]

Прочитал ветку и... предлагаю посмотреть на ситуацию немного с другой стороны.
То, что обсуждается - где-то рядом, но немного "не то".

Давайте рассмотрим "обычную модель общения". Думаю, что у всех есть знакомые, которые пишут сообщения тем способом, который им удобен "здесь и сейчас". Бывает даже так, что задали какой-то вопрос в Viber, не получили там ответ и... написали этот же вопрос в ВК. И им пофигу, где им ответят. О это жуткое время омниканальности...

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

А нам - крайне важно видеть всю историю общения с клиентом именно в рамках одной задачи. Так - очень удобно, т.к. видна динамика работы с клиентом. А в рамках длительной работы - это очень важно. Эта та самая концепция "один клиент - одна задача", о которой я написал в теме про объединение писем в одну задачу

Так что позволю себе заметить, что в модели "одна задача - много каналов связи" есть не только минусы, но и плюсы.

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

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

[Dmitry Goncharenko]

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

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

Противоречие первое.

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

Проще пояснить это на картинках. Сейчас общение выглядит так:




А вот что было бы, если бы менеджеры общались параллельно из разных задач:



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



Противоречие второе

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


Теперь перейдем к обратному ожиданию, которое высказывает Алексей: что контакты-каналы одного клиента можно объединить в одну общую задачу, получать в нее все комментарии по всем этим каналам и при ответе выбирать, по какому именно каналу отправить этот ответ. Основная проблема этого ожидания в том, что оно не существует само по себе: наделив контакт каналом, мы автоматически даем возможность создавать несколько задач на этот контакт и получаем противоречия, описанные выше. При этом, в существующем подходе при желании организовывается такая схема с общей лентой общения с клиентом по всем каналам и переделывать для этого ничего не нужно. Достаточно во всех задачах-каналах установить одного контрагента (созданного дополнительно или любого из контактов, уже созданных по одному из каналов). После этого включаем в карточке этого контрагента опцию:



И видим общую ленту общения с ним. Для ответа по нужному каналу открываем его в новой вкладке и пишем комментарий там.

---

Я не думаю, что тема закрыта - время идет, будут появляться новые кейсы и аргументы. Со своей стороны я готов их принимать и обрабатывать. При этом я все равно вынужден выполнять роль "злой воспитательницы", которая не дает "детям" конфеты - ведь изменения, которые мы делаем в ПланФиксе, распространяются не только на глубоко погруженных в систему и предлагающих ее усовершенствования пользователей, но и на тех, кто познакомился с ПФ только вчера и вообще не планирует лезть в дебри, которые мы тут обсуждаем. А для них важно. чтобы система не позволяла совершать глупые ошибки с неприятными последствиями. И мы, как создатели ПланФикса, вынуждены об этом думать. Поэтому я и выдвигаю на первое место проблемы, подробно описываю их (видите, даже картинки подготовил) и прошу вас не игнорировать это, а сосредоточиться в первую очередь на их разрешении. А выгоды от того или иного нововведения я и сам хорошо умею придумывать :)

[Alexander Koumakov]

Самое главное сделать возможность объединять в один контакт контакт из мессенджеров/соцсетей и контакт из почты в один

[Илья Федоров]

Самое главное сделать возможность объединять в один контакт контакт из мессенджеров/соцсетей и контакт из почты в один

А разве сейчас это нельзя сделать?

[Дмитрий Макаров]

Сейчас в сценариях есть действие Отправить СМС. Одному и тому же контакту может направляться смс из разных задач. Было бы отлично иметь такой пункт для отправки сообщения в Вацап. Это позволило бы автоматизировать процессы оповещения контактов.

[Илья Федоров]

Сейчас в сценариях есть действие Отправить СМС. Одному и тому же контакту может направляться смс из разных задач. Было бы отлично иметь такой пункт для отправки сообщения в Вацап. Это позволило бы автоматизировать процессы оповещения контактов.

Дмитрий тут наверно опять все упирается в то что сообщение в ватсапп можно отправлять только по "задачам" которая создана по каналу ЧАТ API (собственно и есть источник добавления задачи объединяющей в том числе канал API). При этом для исходящего сообщения, если нет активной входящей задачи по этому каналу, создать новую задачу можно только из карточки контакта. Технически ваше пожелание можно решить.
1. В контакте должно быть поле типа задача, в котором указывается задача созданная по каналу whatsAPP, она всегда должна быть в активном статусе.
2. В задаче из которой вы хотите отправлять сообщение по каналу WhatsApp должно быть поле типа задача, куда при создании или при смене контакта нужно сценарием записать задачу из Контакт.ЗадачаWA. То есть у вас в задаче заполнено поле ЗадачаWA = Контакт.ЗадачаWA.
3. В этой задаче, отрабатываете сценарием событие добавлен комментарий содержащий какое-то ключевое слово например !WA, без указания уведомляемых при добавлении такого комментария выполняете действия изменения задачи ЗадачаWA, вы этот комментарий из "главной задачи" со всем его содержимым, дублируете как комментарий в эту задачу ЗадачаWA с уведомлением получателя (в той роли что он у вас подключен, например Постановщик или Исполнитель).
Да логика не совсем очевидная, но вполне рабочая.

[Дмитрий Макаров]

А если сделать настройку в аккаунте или интеграции месенджеров, которая будет вверх к комменту прилеплять например название задачи или ее id или еще какой то идентификатор?

Тогда сообщения контакту будут иметь вид:

Ананасы бананасы

Держите инфу об отгрузке.


Даешь структуированное общение в месенджерах!:)

[Дмитрий Макаров]

Сейчас в сценариях есть действие Отправить СМС. Одному и тому же контакту может направляться смс из разных задач. Было бы отлично иметь такой пункт для отправки сообщения в Вацап. Это позволило бы автоматизировать процессы оповещения контактов.

Дмитрий тут наверно опять все упирается в то что сообщение в ватсапп можно отправлять только по "задачам" которая создана по каналу ЧАТ API (собственно и есть источник добавления задачи объединяющей в том числе канал API). При этом для исходящего сообщения, если нет активной входящей задачи по этому каналу, создать новую задачу можно только из карточки контакта. Технически ваше пожелание можно решить.
1. В контакте должно быть поле типа задача, в котором указывается задача созданная по каналу whatsAPP, она всегда должна быть в активном статусе.
2. В задаче из которой вы хотите отправлять сообщение по каналу WhatsApp должно быть поле типа задача, куда при создании или при смене контакта нужно сценарием записать задачу из Контакт.ЗадачаWA. То есть у вас в задаче заполнено поле ЗадачаWA = Контакт.ЗадачаWA.
3. В этой задаче, отрабатываете сценарием событие добавлен комментарий содержащий какое-то ключевое слово например !WA, без указания уведомляемых при добавлении такого комментария выполняете действия изменения задачи ЗадачаWA, вы этот комментарий из "главной задачи" со всем его содержимым, дублируете как комментарий в эту задачу ЗадачаWA с уведомлением получателя (в той роли что он у вас подключен, например Постановщик или Исполнитель).
Да логика не совсем очевидная, но вполне рабочая.

Значит осталось только научиться автоматически создавать задачи - общение Вацап? Для этого созрела хотелка viewtopic.php?f=32&t=5654