По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Инструменты анализа речи (speech analytics) разрушают единственную защиту от роботов, захватывающих мир: представление о том, что машины не могут понять чувства людей. Выходя далеко за рамки разделения звонков на "хорошие" или "плохие", эмоционально интеллектуальный ИИ (искусственный интеллект) в инструментах речевой аналитики анализирует настроения клиентов, чтобы сказать, предоставляете ли первоклассный "customer service" и действительно ли счастлив ваш клиент.
Средства анализа речи могут дать представление о том, по каким вопросам чаще всего ваши клиенты звонят, обеспечить аналитику поведения агентов в реальном времени и отслеживать изменения "тончайших" метрик.
Мы поговорили с двумя ведущими разработчиками на рынке речевой аналитики чтобы узнать больше о том, как работает аналитика речи и почему эти инструменты стоят вашего внимания.
Максимальный результат
Сборщики долгов (коллекторы), которые стали одними из первых, кто применил в своей практике программное обеспечение анализа речи, используют его не только для того, чтобы убедиться соблюдаются ли агентами нормативные требования (закон), но и для улучшения качества обслуживания клиентов.
Вы будете удивлены, но да, даже сборщики долгов заботятся о том, как вы себя чувствуете в эмоциональном плане так как от этого зависит, смогут ли они уговорить вас оплатить долг.
В некоторых компаниях в начале звонка агенты должны предоставить заявление о соответствии, например, поставщик медицинских услуг, разъясняющий пациенту политику конфиденциальности. Программа анализа речи может извещать агента напоминанием, если он не сделал этого в течение определенного времени.
"Алгоритм основан на отсутствии коммуникационных фраз в диалоге. Речевая аналитика в реальном времени позволяет как раз отслеживать этот триггер, пока нужная фраза не будет озвучена. " - пояснил наш собеседник.
Возможность отслеживать звонки в режиме реального времени еще важнее для организаций, которые предоставляют юридические консультации или, скажем, рекомендации по страховым льготам. Говоря о кейсах, наш собеседник сослался на менеджера по контролю качества в компании, которая предоставляет предприятиям HR консультации. Так, клиенту компании, было поручено контролировать агентов, которые должны очень точно предоставлять информацию или нести ответственность за ущерб, если клиент пытается подать страховую претензию и есть проблема с зачислением или соблюдением.
"Одна из проблем заключается в том, что мы действительно ведем сложные с точки зрения процесса диалоги. У нас 19 различных бизнес - сценариев, представленных в формате скриптов, которые должны быть последовательно отработаны операторами".
Большинство средств анализа речи предоставляют полные транскрибации (стенограммы, расшифровки) и записи вызовов, а также анализ после звонка, который оценивает качество обслуживания. Ведущие платформы предоставляют аналитику в режиме реального времени, которая может посылать предупреждения менеджеру или управляющему, или извлекать определенную статью из базы знаний для агента.
Например, если агент пытается продать продукт, а клиент ссылается на продукт конкурента или рекламную акцию, программное обеспечение может выдвинуть соответствующее предложение из CRM-системы, чтобы агент мог сделать встречное предложение: "Ну, мы можем сделать вам предложение получше. Вот наша последняя кампания...".
Помимо помощи КЦ в оценке обычных KPI, таких как FCR (First call resolution, решение вопроса с первого звонка), речевая аналитика обеспечивает глубокое погружение в вопрос, который мы все просто не можем удержаться, чтобы не задать нашим клиентам: "Как я вас обслужил? Остались ли вы счастливы?"
Живой кейс: после использования инструмента речевой аналитики, известный игрок на рынке потребительских товаров обнаружил продуктовый дефект после того, как программное обеспечение речевой аналитики КЦ в качестве основной причины резкого увеличения объема вызовов отметило повторяющуюся жалобу на вполне конкретную проблему.
"Отметив всплеск обращения в КЦ по конкретному продуктовому дефекту, компания провели исследование в социальных сетях и проблема подтвердилась".
Когда речь идет о продажах, компании постоянно оттачивают процессы и скрипты продаж. Используя инструменты речевой аналитики для просмотра звонков, которые закончились успешной продажей, один из крупнейших продавцов систем инфраструктурной безопасности создал проект, чтобы помочь продавцам увеличить продажи.
"Они просто проанализировали звонки, которые закончились продажей. По итогам анализа, в разговорах успешных продавцов были выявлены паттерны и вполне понятные закономерности. Это позволило значительно улучшить процесс и бустануть отделу продаж."
Средства аналитики также могут помочь компании устранить внутренние недостатки в работе службы поддержки клиентов, такие как пробелы в знаниях/компетенции или чрезмерные переводы вызовов.
"Используя аналитику, можно провести конкретные измерения: почему переводятся звонки клиентов, почему агентам требуется больше времени для решения их вопроса"
Человеко - ориентированный подход к клиентскому сервису
Речевая аналитика не только хранит и анализирует данные, но и дает проактивные рекомендации агентам по обеспечению качества обслуживания. ПО может "пушить" агентам автоматизированные предложения и подсказки в реал тайме и даже немного потренировать их.
Важно не переборщить с роботизацией этого процесса. Люди останутся благодарны и счастливы от человеческого отношения к ним и к их вопросу. Поэтому, дальновидные компании стремятся к более ориентированному на человека подходу к обслуживанию клиентов, предоставляя своим агентам тренинги по развитию эмпатии, а на основными метриками успеха работы агента становятся "софт - метрикс" (мягкие), такие как эмоциональный контакт, открытость и дружественное отношение.
Логичный вопрос: разве автоматизация процессов голосовой поддержки клиентов не противоречит человеко - ориентированному подходу?
По словам нашего собеседника, один из первых клиентов компании использовал ручную оценку вызовов, где менеджер контроля качества отмечал пункты из контрольного списка, прослушивая каждый разговор отдельно (скоркарды, ну вы знаете).
Компания внедрила инструмент речевой аналитики, что позволило агентам стать самим собой: более никакого жесткого соответствия скрипту разговора, где в случае чего, "шаг вправо, шаг влево - снижение премии". Агенты стали более искренними и естественными, что позитивно отражалось на их премии. ПО трекало тонкое соответствие процессу обслуживания, определяя тематики и понятия в разговоре, без жесткой привязки к конкретным словами, которые агент обязан был сказать. Все - клиенты, агенты и сама по себе компания стали счастливы.
Фактически, обратная связь от анализа речи может даже заставить организации развернуть свою стратегию CS.
На самом деле, речевая аналитика порой приносит весьма шокирующие "инсайты", которые мотивируют компании на кардинальные изменения в процессе клиентского сервиса и продаж.
"Мы видели, как несколько клиентов находили неожиданные инсайты, которых они совершенно не ожидали. Например, как оказалось, измеряя AHT (average handle time, среднее время обработки вызова) как метрику и традиционно пытаясь ее уменьшать, ребята поняли, что более длительные звонки (по измеренной когорте клиентов) по времени разговора звонки приводят к увеличению LTV (life time value) в денежном эквиваленте".
Масштабирование контроля качества в КЦ
Перегруженные менеджеры по контролю качества (супервайзеры) в КЦ слушают и проверяют 5 - 10 вызовов на одного агента в месяц. В среднем по отрасли, соотношение количества супервайзеров к агентам это 1 к 20, а среднее время одного вызова около 4 минут.
"Даже если взять минимальное значение вызовов для контроля на супервайзера (5 штук), то получается, что супервайзер 4,16% своего рабочего времени тратит просто на то, чтобы сидеть в наушниках и слушать голоса агентов."
Для компаний в сфере консалтинга, среднее время обработки может быть намного больше, что еще больше утяжеляет процесс контроля качества. Например, сложные звонки юридической тематики часто длятся по 25-50 минут.
После реализации речевой аналитики, анализу подлежат 100 процентов вызовов. Не это ли масштабирование контроля качества до его предела?
Геймификация КЦ для агентского импульса
Система анализа речи помогает геймифицировать процесс клиентского сервиса. Например, один из клиентов установил дашборд реального времени в опен спейсе КЦ, в котором в формате ежедневного первенства между операторами показывался рейтинг по совокупности звонков. Условно говоря, рейтинг формировался инструментом речевой аналитики, проставляя оценки каждому из звонков по соответствие тем или иным метрикам.
Тем самым, сопровождая такие геймифицированные процессы вполне осязаемой материальной мотивацией, агенты соревнуются в качестве обслуживания, тем самым, ускоряя процесс обучения и повышая лояльность клиентов. Бинго.
Топовые компании на рынке речевой аналитики
Мы составили небольшой рейтинг платформ по речевой аналитике для КЦ уровня энтерпрайз на Российском рынке.
NICE
NICE inContact - один из лидеров по разработке платформ улучшения клиентского опыта взаимодействия с компаниями. Помимо популярного продукта речевой аналитики, вендор имеет ряд решений для омниканальнго обслуживания, WFO и богатую ML/AI экспертизу.
Почитать больше: www.niceincontact.com
Verint Speech Analytics
Продолжаем экскурсию по энтерпрайзным КЦ решениям. Verint Speech Analytics позволит транскрибировать и анализировать миллионы звонков, чтобы находить клиентские инсайты улучшать производительность контактного центра.
Почитать больше: www.verint.com/ru/speech-analytics
ZOOM (Eleveo) Speech Analytics
В РФ у ZOOM (Eleveo) сильно популярная система записи, известная под названием ZOOM CallRec. Однако, чешский производитель имеет в своем портфеле достаточно мощный инструмент речевой аналитики.
Вендор предоставляет следующие преимущества своего продукта:
Быстрая скорость работы, как следствие богатой экспертизы ML/AI команды разработчика;
Легкость в использовании;
Анализ эмоций
Интеграция с подсистемой записи сразу;
Инсайты по работе КЦ в удобной форме.
Почитать больше: www.zoomint.com/solutions/speech-analytics
Перед начало убедитесь, что ознакомились с материалом про построение деревьев в сетях.
Правило кратчайшего пути, является скорее отрицательным, чем положительным экспериментом; его всегда можно использовать для поиска пути без петель среди набора доступных путей, но не для определения того, какие другие пути в наборе также могут оказаться свободными от петель. Рисунок 4 показывает это.
На рисунке 4 легко заметить, что кратчайший путь от A до пункта назначения проходит по пути [A, B, F]. Также легко заметить, что пути [A, C, F] и [A, D, E, F] являются альтернативными путями к одному и тому же месту назначения. Но свободны ли эти пути от петель? Ответ зависит от значения слова "без петель": обычно путь без петель - это такой путь, при котором трафик не будет проходить через какой-либо узел (не будет посещать какой-либо узел в топологии более одного раза). Хотя это определение в целом хорошее, его можно сузить в случае одного узла с несколькими следующими переходами, через которые он может отправлять трафик в достижимый пункт назначения. В частности, определение можно сузить до:
Путь является свободным от петель, если устройство следующего прыжка не пересылает трафик к определенному месту назначения обратно ко мне (отправляющему узлу).
В этом случае путь через C, с точки зрения A, можно назвать свободным от петель, если C не пересылает трафик к месту назначения через A. Другими словами, если A передает пакет C для пункта назначения, C не будет пересылать пакет обратно к A, а скорее пересылает пакет ближе к пункту назначения. Это определение несколько упрощает задачу поиска альтернативных путей без петель. Вместо того, чтобы рассматривать весь путь к месту назначения, A нужно только учитывать, будет ли какой-либо конкретный сосед пересылать трафик обратно самому A при пересылке трафика к месту назначения.
Рассмотрим, например, путь [A, C, F]. Если A отправляет пакет C для пункта назначения за пределами F, переправит ли C этот пакет обратно в A? Доступные пути для C:
[C, A, B, F], общей стоимостью 5
[C, A, D, E], общей стоимостью 6
[C, F], общей стоимостью 2
Учитывая, что C собирается выбрать кратчайший путь к месту назначения, он выберет [C, F] и, следовательно, не будет пересылать трафик обратно в A. Превращая это в вопрос: почему C не будет перенаправлять трафик обратно в A? Потому что у него есть путь, стоимость которого ниже, чем у любого пути через A до места назначения. Это можно обобщить и назвать downstream neighbor:
Любой сосед с путем, который короче локального пути к месту назначения, не будет возвращать трафик обратно ко мне (отправляющему узлу).
Или, скорее, учитывая, что локальная стоимость представлена как LC, а стоимость соседа представлена как NC, тогда:
Если NC LC, то тогда neighbor is downstream.
Теперь рассмотрим второй альтернативный путь, показанный на рисунке 4: [A, D, E, F]. Еще раз, если A отправляет трафик к пункту назначения к D, будет ли D зацикливать трафик обратно к A?
Имеющиеся у D пути:
[D, A, C, F], общей стоимостью 5
[D, A, B, F], общей стоимостью 4
[D, E, F], общей стоимостью 3
Предполагая, что D будет использовать кратчайший доступный путь, D будет пересылать любой такой трафик через E, а не обратно через A. Это можно обобщить и назвать альтернативой без петель (Loop-Free Alternate -LFA):
Любой сосед, у которого путь короче, чем локальный путь к месту назначения, плюс стоимость доступа соседа ко мне (локальный узел), не будет возвращать трафик обратно ко мне (локальному узлу).
Или, скорее, учитывая, что локальная стоимость обозначена как LC, стоимость соседа обозначена как NC, а стоимость обратно для локального узла (с точки зрения соседа) - BC:
Если NC + BC LC, то сосед - это LFA.
Есть две другие модели, которые часто используются для объяснения Loop-Free Alternate: модель водопада и пространство P/Q. Полезно посмотреть на эти модели чуть подробнее.
Модель водопада (Waterfall (or Continental Divide) Model).
Один из способов предотвратить образование петель в маршрутах, рассчитываемых плоскостью управления, - просто не объявлять маршруты соседям, которые пересылали бы трафик обратно мне (отправляющему узлу). Это называется разделенным горизонтом (split horizon). Это приводит к концепции трафика, проходящего через сеть, действующую как вода водопада или вдоль русла ручья, выбирая путь наименьшего сопротивления к месту назначения, как показано на рисунке 5.
На рисунке 5, если трафик входит в сеть в точке C (в источнике 2) и направляется за пределы E, он будет течь по правой стороне кольца. Однако, если трафик входит в сеть в точке A и предназначен для выхода за пределы E, он будет проходить по левой стороне кольца. Чтобы предотвратить зацикливание трафика, выходящего за пределы E, в этом кольце, одна простая вещь, которую может сделать плоскость управления, - это либо не позволить A объявлять пункт назначения в C, либо не позволить C объявлять пункт назначения в A. Предотвращение одного из этих двух маршрутизаторов от объявления к другому называется разделенным горизонтом (split horizon), потому что это останавливает маршрут от распространения через горизонт, или, скорее, за пределами точки, где любое конкретное устройство знает, что трафик, передаваемый по определенному каналу, будет зациклен.
Split horizon реализуется только за счет того, что устройству разрешается объявлять о доступности через интерфейсы, которые оно не использует для достижения указанного пункта назначения. В этом случае:
D использует E для достижения пункта назначения, поэтому он не будет объявлять о доступности в направлении E
C использует D для достижения пункта назначения, поэтому он не будет объявлять о доступности D
B использует E для достижения пункта назначения, поэтому он не будет объявлять о доступности в направлении E
A использует B для достижения пункта назначения, поэтому он не будет объявлять о доступности B
Следовательно, A блокирует B от знания альтернативного пути, который он имеет к месту назначения через C, а C блокирует D от знания об альтернативном пути, который он имеет к месту назначения через A. Альтернативный путь без петель пересекает этот разделенный горизонт. точка в сети. На рис. 12-5 A может вычислить, что стоимость пути C меньше стоимости пути A, поэтому любой трафик A, направляемый в C к месту назначения, будет перенаправлен по какому-то другому пути, чем тот, о котором знает A. C, в терминах LFA, является нижестоящим соседом A.
Следовательно, A блокирует B от знания об альтернативном пути, который он имеет к месту назначения через C, и C блокирует D от знания об альтернативном пути, который он имеет к месту назначения через A. Альтернативный путь без петли будет пересекать эту точку split horizon в сети. На рисунке 5 A может вычислить, что стоимость пути C меньше стоимости пути A, поэтому любой трафик A, направленный в C к месту назначения, будет перенаправлен по какому-то другому пути, чем тот, о котором знает A. В терминах LFA, С является нижестоящим соседом (downstream neighbor) A.
P/Q пространство
Еще одна модель, описывающая, как работают LFA, - это пространство P / Q.
Рисунок 6 иллюстрирует эту модель.
Проще всего начать с определения двух пространств.
Предполагая, что линия связи [E, D] должна быть защищена от сбоя:
Рассчитайте Shortest Path Tree из E (E использует стоимость путей к себе, а не стоимость от себя, при вычислении этого дерева, потому что трафик течет к D по этому пути).
Удалите линию связи [E,D] вместе с любыми узлами, доступными только при прохождении через эту линию.
Остальные узлы, которых может достичь E, - это пространство Q.
Рассчитайте Shortest Path Tree из D.
Удалите канал [E, D] вместе со всеми узлами, доступными только при прохождении по линии.
Остальные узлы, которых может достичь D, находятся в пространстве P.
Если D может найти маршрутизатор в пространстве Q, на который будет перенаправляться трафик в случае отказа канала [E, D]- это LFA.
Удаленные (remote) Loop-Free Alternates
Что делать, если нет LFA? Иногда можно найти удаленную альтернативу без петель (remote Loop-Free Alternate - rLFA), которая также может передавать трафик к месту назначения. RLFA не подключен напрямую к вычисляющему маршрутизатору, а скорее находится на расстоянии одного или нескольких переходов. Это означает, что трафик должен передаваться через маршрутизаторы между вычисляющим маршрутизатором и remote next hop. Обычно это достигается путем туннелирования трафика.
Эти модели могут объяснить rLFA, не обращая внимания на математику, необходимую для их расчета. Понимание того, где кольцо "разделится" на P и Q, или на две половины, разделенные split horizon, поможет вам быстро понять, где rLFA можно использовать для обхода сбоя, даже если LFA отсутствует. Возвращаясь к рисунку 6, например, если канал [E, D] выходит из строя, D должен просто ждать, пока сеть сойдется, чтобы начать пересылку трафика к месту назначения. Лучший путь от E был удален из дерева D из-за сбоя, и E не имеет LFA, на который он мог бы пересылать трафик.
Вернитесь к определению loop-free path, с которого начался этот раздел-это любой сосед, к которому устройство может перенаправлять трафик без возврата трафика. Нет никакой особой причины, по которой сосед, которому устройство отправляет пакеты в случае сбоя локальной линии связи, должен быть локально подключен. В разделе "виртуализация сети" описывается возможность создания туннеля или топологии наложения, которая может передавать трафик между любыми двумя узлами сети.
Учитывая возможность туннелирования трафика через C, поэтому C пересылает трафик не на основе фактического пункта назначения, а на основе заголовка туннеля, D может пересылать трафик непосредственно на A, минуя петлю. Когда канал [E, D] не работает, D может сделать следующее:
Вычислите ближайшую точку в сети, где трафик может быть туннелирован и не вернется к самому C.
Сформируйте туннель к этому маршрутизатору.
Инкапсулируйте трафик в заголовок туннеля.
Перенаправьте трафик.
Примечание. В реальных реализациях туннель rLFA будет рассчитываться заранее, а не рассчитываться во время сбоя. Эти туннели rLFA не обязательно должны быть видимы для обычного процесса пересылки. Эта информация предоставлена для ясности того, как работает этот процесс, а не сосредоточен на том, как он обычно осуществляется.
D будет перенаправлять трафик в пункт назначения туннеля, а не в исходный пункт назначения - это обходит запись локальной таблицы переадресации C для исходного пункта назначения, что возвращает трафик обратно в C. Расчет таких точек пересечения будет обсуждаться в чуть позже в статьях, посвященных первому алгоритму кратчайшего пути Дейкстры.
Битрикс24 – облачная CRM система, цель которой заключается в повышении эффективности работы компании. Мы можем выделить 3 позиции, которые привлекают внимание предпринимателей к этой системе:
Доступность - для начинающих предпринимателей Битрикс24 бесплатна по тарифу «Проект». В бесплатной версии вы можете вести обработку лидов, сделок, ставить задачи, создавать проекты, выставлять счета и многие другие опции. В бесплатной версии нет возможности создавать бизнес – процессы. Более высокие версии, такие как «Команда» или «Компания» обладают более богатым функционалом за привлекательную цену.
Омниканальность - вся деятельность по различным каналам работы будет сконцентрирована в Битрикс24. Без разницы, напишет ли клиент письмо на общий адрес электронной почты компании, или на адрес менеджера персонально, напишет в Telegram, Вконтакте, Facebook, заполнит форму на сайте или позвонит – автоматические будет создан лид в CRM и обработан согласно внутренним правилам в зависимости от источника.
Гибкость - CRM система имеет приложение для ПК, смартфона и планшета. Важно отметить, что существует специальный REST API, с помощью которого можно создавать лиды с помощью PHP с сайта. Коробочную версию CRM можно дорабатывать с помощью собственных PHP скриптов.
Если вы остановили свой выбор на Битрикс24 и ищете возможности автоматизировать обработку лидов, то в статье мы расскажем о интеграции Битрикс24 с сайтом.
Интеграция Битрикс24 с сайтом
Начнем с создания HTML формы на сайте по примеру ниже:
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<form action="integration.php" method="post">
Тема: <input type="text" name="tema" value="" /><br />
Ваша компания: <input type="text" name="companyname" value="" /><br />
Имя: <input type="text" name="name" value="" /><br />
Фамилия: <input type="text" name="lastname" value="" /><br />
Ваше сообщение: <textarea name="message"></textarea><br />
<input type="submit" value="Send" />
</form>
</html>
Здесь, методом POST, мы будем передавать параметры в PHP файл, который в свою очередь будет связывать наш сайт с Битрикс24. Скопированную сверху конфигурацию сохраняем в файл, который называем integration.php
Продолжаем работу с этим файлом. Над скопированной выше конфигурации открываем PHP – тэг с помощью символов <?php . Между php и вторым знаком вопроса мы будем вставлять последующую конфигурацию.
Определяем необходимые для REST API переменные, с помощью которых мы будем определять адрес сервера подключения и параметры авторизации. Заранее создайте в Битрикс24 пользователя с правами на создание и изменение сущностей связанных с лидами. В конфигурации приведены строки с комментариями:
// Параметры подключения к вашему облачному Битрикс24
define('CRM_HOST', 'your_domain.bitrix24.com'); // укажите здесь ваш домен в Битрикс
define('CRM_PORT', '443'); // порт для подключения. Здесь оставляем все как есть
define('CRM_PATH', '/crm/configs/import/lead.php'); // Путь к PHP файлу, к которому будем подлючаться. Здесь оставляем все как есть
// Параметры авторизации
define('CRM_LOGIN', 'login'); // логин пользователя, которого мы создали для подключения
define('CRM_PASSWORD', 'password'); // пароль пользователя CRM
Переходим к самому скрипту, который будет заниматься отправкой данных в CRM
$tema = $_POST['tema']; //получаем значение полей из формы и записываем их в переменные методом POST
$companyname = $_POST['companyname'];
$name = $_POST['name'];
$lastname = $_POST['lastname'];
$message = $_POST['message'];
// Начинаем обработку внутри скрипта
if ($_SERVER['REQUEST_METHOD'] == 'POST')
{
$leadData = $_POST['DATA'];
// представляем массив
$postData = array(
'TITLE' => $tema,
'COMPANY_TITLE' => $companyname,
'NAME' => $name,
'LAST_NAME' => $lastname,
'COMMENTS' => $message,
);
// добавляем в массив параметры авторизации
if (defined('CRM_AUTH'))
{
$postData['AUTH'] = CRM_AUTH;
}
else
{
$postData['LOGIN'] = CRM_LOGIN;
$postData['PASSWORD'] = CRM_PASSWORD;
}
// открываем сокет соединения к облачной CRM
$fp = fsockopen("ssl://".CRM_HOST, CRM_PORT, $errno, $errstr, 30);
if ($fp)
{
// производим URL-кодирование строки
$strPostData = '';
foreach ($postData as $key => $value)
$strPostData .= ($strPostData == '' ? '' : '&').$key.'='.urlencode($value);
// подготавливаем заголовки
$str = "POST ".CRM_PATH." HTTP/1.0
";
$str .= "Host: ".CRM_HOST."
";
$str .= "Content-Type: application/x-www-form-urlencoded
";
$str .= "Content-Length: ".strlen($strPostData)."
";
$str .= "Connection: close
";
$str .= $strPostData;
fwrite($fp, $str);
$result = '';
while (!feof($fp))
{
$result .= fgets($fp, 128);
}
fclose($fp);
$response = explode("
", $result);
$output = '<pre>'.print_r($response[1], 1).'</pre>';
}
else
{
echo 'Не удалось подключиться к CRM '.$errstr.' ('.$errno.')';
}
}
else
{
}
В случае, если вы хотите провести «дебаг» соединения и понять в чем могут быть проблемы, в разделе HTML кода добавьте следующий код, который позволит вывести причину неработоспособности:
<?php echo $output;
Сохраняем все внесенные конфигурации и переходим к тесту. Заполняем WEB – форму:
Как результат, в CRM появляется лид:
Лид успешно создан в CRM. Для его обработки вы можете создать различные бизнес процессы в разделе «Настройки» -> «Автоматизация». Сам файл скрипта вы можете скачать по ссылке ниже. После загрузки, измените формат файла на PHP:
Скачать скрипт интеграции с сайтом