Идеи пользователя 170340

если в битриксе объединить 2 компании - то через REST api об этом никак не узнать.

При этом если выполнить запрос по crm.company.get по удаленному id то в ответ получим только {"error":"","error_description":"Not found"}

Если бы в этом ответе было еще одно поле merged_with id то счастье бы наступило немедленно в области синхронизации.

Я получу этот ид и повторю операцию объединения в базе 1С.
Если этого не сделать - то при следующем обмене 1С увидит "нового" не синхронизированного контрагента и выдавит его в битрикс. и опять придется бороться с дублями.

добавьте в crm.company.get и crm.contact.get поле с информацией о выжившем после объединения id

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

Нужна настройка видимости полей или разделов в зависимости от направления сделки.

Есть проверка заполнения в зависимости от стадии.
Наверное такую же механику можно было бы использовать и для настройки видимости в зависимости от стадии.

Клиент на сайте авторизован, т.е. сайт уже знает его данные - ФИО, телефон, e-mail и Город проживания.
Стучится в открытые линии и мы его снова просим представится. Показываем эту форму для заполнения контактов.
Можно же данные клиента сразу передать в чат, и чат будет открываться с уже заполненной формой. Оператор сразу видит кто это.

Нужно посчитать среднюю длительность сделки в днях в разрезе по менеджерам и/или по товарам по всем закрытым удачным сделкам и по всем закрытым неудачным сделкам.
Отчет должен давать возможность выбирать период.
Зачем?

В разрезе менеджеров смотрим.
Если в среднем длина сделки 80 дней, а у менеджера А много проигранных сделок длиной 60 дней, то он явно торопится и недостаточно плотно общается с клиентами.
Или.
У менеджера А сделки закрываются успешно в среднем за 30 дней.
А у менеджера Б в среднем уходит 50 дней - значит ему надо поучиться у А и перенять техники которые ему позволяют закрывать свои сделки быстрее.

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

В общем никак без этой информации. И где взять?

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

Например в гостиницах при заказе номера требуется указать дату заезда и дату выезда. И если в одном заказе несколько номеров на разные даты?
Или при заказе мероприятия - разные услуги оказываются в разные даты. Где эти даты указать?

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

Нужен сценарий по приему звонков "сразу всем".

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

Когда мы в Манго перешли на такую схему стало лучше. Клиенты перестали жаловаться. На звонок отвечают почти сразу же. Сотрудникам стало спокойнее, им не надо беспокоится, что если не успеет до 3 гудков поднять, то звонок убежит.

После того как сделка заведена, часто требуется обсудить сделку, дать по ней комментарий.
Например нужно обсудить сумму или скидку, или я, как руководитель, могу предложить менеджеру идеи для допродажи услуг.
Как вести все эти обсуждения? Через задачи?

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

Добавьте комментарии к сделке, с таким же поведением как и комментарии задачи.