Особенности интеграции amoCRM
с МИС IDENT
В последнее время нам всё чаще стал поступать следующий вопрос от клиентов, которые обращаются за связкой между МИС IDENT и amoCRM: “А можно сделать двустороннюю связку между МИС IDENT и amoCRM? Так, чтобы данные передавались как из МИС IDENT в amoCRM, так и обратно?”. В нашей статье мы подробно рассказали, почему пришли к выводу, что самым эффективным форматом реализации связки между двумя системами является передача данных из МИС IDENT в amoCRM, а не наоборот.
“Синхронизация, при которой данные о пациенте (номер телефона, ФИО пациента, ФИО врача, дата и время записи) передаются из amoCRM в IDENT возможна, но в таком случае данные передаются в виде заявки в раздел CRM в подраздел "История обращений" в IDENT, где сотрудник должен открыть диалоговое окно, выбрать в календаре дату и время приёма, заполнить остальные данные о приеме и создать его. Логика работы в IDENT предполагает, создание заявок, которые необходимо сотруднику клиники подтверждать и только после создавать прием. То есть каждую новую заявку в IDENT сотрудник клиники должен проверять и сохранять вручную… Хотя, по логике, если у нас есть данные о приеме (номер телефона, ФИО пациента, ФИО врача, дата и время записи), то эта работа уже была выполнена и зафиксирована ранее в amoCRM! Поэтому работа в таком формате была возможна, но неудобна. Сразу, из amoCRM, передавать данные и создавать запись на приём в IDENT, - невозможно (ограничение IDENT). При данном варианте интеграции все равно присутствовало промежуточное звено в виде заявки, которую было необходимо вручную обрабатывать в IDENT. Что в итоге приводило к двойной работе!”
Алексей Яновский
Руководитель компании REON
Нам было непонятно, почему клиенты стали задаваться вопросом о двусторонней связке, когда мы объясняли неэффективность и минимальный набор функционала при передаче данных из amoCRM в IDENT. Но проведя конкурентный анализ, всё стало на свои места… Мы столкнулись с тем, что компании-интеграторы обещают клиентам то, что технически невозможно реализовать! Просто потому что заказчики не разбираются в возможностях и ограничениях МИС IDENT. Такие компании обещают, что передача любых необходимых данных из amoCRM в IDENT возможна, и что администраторам/операторам call-центра/кураторам вообще не придется заходить в МИС IDENT и в ней будут работать только врачи. Но в итоге оказывается, что ранее компания либо вообще не реализовывала данную связку, либо выполняла связку между amoCRM и другой медицинской информационной системой, считая, что все системы одинаковые и не возникнет никаких сложностей и подводных камней. По факту вы отдаете компании свои деньги и становитесь подопытным объектом, на котором интегратор будет тестировать свои гипотезы. Но что самое обидное, гипотезы в итоге не станут реальностью, потому что изначально обещания были технически нереализуемыми.
В данной статье мы подробно расскажем, что возможно реализовать во время связки между МИС IDENT и amoCRM, а что нет и почему. Опираться при этом мы будем на техническую документацию, которая есть в открытом доступе на сайте IDENT. Поэтому данная статья - это не наше мнение и не наши догадки, это прямые технические требования и указания МИС IDENT, которые были глубоко изучены и проанализированы нашей компанией, подтверждены технической поддержкой IDENT и для вашего удобства простым языком изложены ниже.
В данной статье мы подробно расскажем, что возможно реализовать во время связки между МИС IDENT и amoCRM, а что нет и почему. Опираться при этом мы будем на техническую документацию, которая есть в открытом доступе на сайте IDENT. Поэтому данная статья - это не наше мнение и не наши догадки, это прямые технические требования и указания МИС IDENT, которые были глубоко изучены и проанализированы нашей компанией, подтверждены технической поддержкой IDENT и для вашего удобства простым языком изложены ниже.
Особенности интеграции с IDENT
1.⠀“Так как IDENT находится внутри клиники, любой способ прямого обращения к ней извне будет ненадежен. Единственный надежный вариант в данной ситуации — регулярное обращение к внешним сервисам со стороны IDENT. Этот процесс осуществляется фоновыми задачами, повторяющимися через определенные интервалы времени.”
Простым языком данная фраза означает, что мы не можем напрямую передавать данные из внешних источников в базу данных IDENT. Как пишет сам IDENT: “Обращения к базе данных IDENT невозможны, web-сервера у IDENT не существует, все операции производятся программой в виде запросов на получение данных или запросов с отправкой данных к серверам поставщиков”.
То есть работа МИС IDENT строится по принципу запроса данных из внешнего мира. Сама МИС через определенные адреса подключения может смотреть во внешние базы данных, которые расположены на стороне, и получать из них определенную информацию в регламентированном самим IDENT формате. Фактически не сторонняя платформа или сервис решает, какую информацию передать в IDENT, а сама IDENT решает, какую информацию ей запросить и сохранить к себе из внешнего источника. И при этом IDENT может забрать себе ограниченную часть информации, которая подходит под её структуру передаваемых данных.
То есть работа МИС IDENT строится по принципу запроса данных из внешнего мира. Сама МИС через определенные адреса подключения может смотреть во внешние базы данных, которые расположены на стороне, и получать из них определенную информацию в регламентированном самим IDENT формате. Фактически не сторонняя платформа или сервис решает, какую информацию передать в IDENT, а сама IDENT решает, какую информацию ей запросить и сохранить к себе из внешнего источника. И при этом IDENT может забрать себе ограниченную часть информации, которая подходит под её структуру передаваемых данных.
2.⠀“У IDENT нет отдельного сервиса, который выполняет интеграции. Это реализовано на «Клиентах». «Клиент» — это каждая запущенная копия программы. На одном компьютере может быть запущено одновременно несколько копий. Интеграции возможны только при работающем клиентском компьютере, а единственный «Клиент», который запущен все время работы клиники, это «Клиент» под ролью «Администратор».”
Зачастую, когда разработчики делают какое-то грамотное программное обеспечение, - они создают ряд внутренних микросервисов, которые помогают этому программному обеспечению работать автономно.
У МИС IDENT нет такого внутреннего сервиса, который бы отвечал за работу именно интеграций. То есть за работу интеграций отвечает то же самое приложение, в котором работают ваши сотрудники. И в этом и заключается проблема, потому что для интеграции нужна копия программы, которая будет работать 24/7 на отдельном клиентском компьютере, чтобы интеграции также работали 24/7. Поэтому для реализации интеграции IDENT с другой системой, - необходимо иметь свои серверы с хранением и обработкой информации в соответствии с определенными требованиями IDENT, чтобы данные для синхронизации, в случае выключения всех копий программы IDENT, не пропали и после включения были переданы.
В итоге, как пишет сам IDENT, у нас есть всего два варианта для реализации сторонней связки:
Первый - это прямой доступ к СУБД (системе управления базами данных), поддерживаются MsSQL и MySQL. Рекомендуется (из соображений безопасности) только при нахождении «Клиентов» IDENT в той же локальной сети, что и реализуемый сервер (базу данных), который мы хотим создать.
У МИС IDENT нет такого внутреннего сервиса, который бы отвечал за работу именно интеграций. То есть за работу интеграций отвечает то же самое приложение, в котором работают ваши сотрудники. И в этом и заключается проблема, потому что для интеграции нужна копия программы, которая будет работать 24/7 на отдельном клиентском компьютере, чтобы интеграции также работали 24/7. Поэтому для реализации интеграции IDENT с другой системой, - необходимо иметь свои серверы с хранением и обработкой информации в соответствии с определенными требованиями IDENT, чтобы данные для синхронизации, в случае выключения всех копий программы IDENT, не пропали и после включения были переданы.
В итоге, как пишет сам IDENT, у нас есть всего два варианта для реализации сторонней связки:
Первый - это прямой доступ к СУБД (системе управления базами данных), поддерживаются MsSQL и MySQL. Рекомендуется (из соображений безопасности) только при нахождении «Клиентов» IDENT в той же локальной сети, что и реализуемый сервер (базу данных), который мы хотим создать.
Подробные требования для такого варианта реализации перечислены здесь.
Для реализации данного способа связки нам необходимо создать БД (базу данных) с определенным набором таблиц и произвести настройки в программе IDENT, чтобы IDENT забирал из нашей БД информацию в свою БД.
Но при такой интеграции мы сталкиваемся с рядом сложностей. Одна из них - это ограниченное количество возможностей для обмена данными.
Сам IDENT предполагает, что интеграции можно разделить на три независимых задачи:
Но при такой интеграции мы сталкиваемся с рядом сложностей. Одна из них - это ограниченное количество возможностей для обмена данными.
Сам IDENT предполагает, что интеграции можно разделить на три независимых задачи:
- Интеграция с телефонией, когда IDENT смотрит в стороннюю БД (хранилище)) и забирает данные. То есть он с помощью рекуррентных задач с определенной периодичностью (например, каждую минуту) смотрит во внешнюю базу данных и забирает из нее новые полученные данные в определенном регламентированном формате и структуре. Опять же, не телефония передает эти данные, а IDENT сам их забирает к себе в БД.
- Выгрузка расписания, когда мы хотим на какой-то сторонней площадке показать в онлайн-формате расписание врачей, чтобы пациенты могли самостоятельно выбрать дату и время приема. В этой ситуации данные уже передаются из IDENT во внешнюю БД. То есть опять же, IDENT подключается к сторонней базе данных и передает туда свою информацию о свободных слотах на приемы. Но проблема заключается в том, что многие платформы работают именно через API и не могут дать доступ к своей БД.
- Получение заявок с таких сайтов как «НаПоправку», «ПроДокторов», СберЗдоровье, 32top. IDENT аналогично смотрит в стороннюю БД и забирает из нее новые данные. Но есть такие площадки и конструкторы сайтов, например как Tilda, у которых нет такого хранилища с заявками, и получается IDENT к ним физически не может подключиться для сбора данных. Именно по этой причине у IDENT нет готовой связки с Tilda, Wix и другими конструкторами сайтов.
И из этого всего вытекает вторая проблема, что такая заявка в IDENT приходит в виде обращения, которое еще необходимо проверить и подтвердить. То есть каждый раз с приходом новой заявки в IDENT, - администратор/оператор call-центра/куратор должен перейти в подраздел "История обращений", открыть диалоговое окно, вручную дозаполнить карточку, выбрав время и врача, которые указал клиент при обращении, и после этого сохранить данные и записать пациента на прием.
Такой формат интеграции мы создавали три года назад, когда только делали первые попытки реализации связки между IDENT и amoCRM. И именно такая синхронизация была настроена нашим первым клиентам-стоматологиям. Но в итоге работать в таком формате было по-прежнему неудобно. Вести пациентов приходилось все равно в двух системах, плюс из-за того, что IDENT может принимать данные только в качестве новых заявок, то для записи каждого пациента нужно было в ручном режиме вносить всю информацию повторно. Сразу, из amoCRM, передавать данные и создавать запись на приём в IDENT, - невозможно! При данном варианте интеграции все равно присутствовало промежуточное звено в виде заявки, которую было необходимо обрабатывать в IDENT, что еще больше осложняло работу администраторов/операторов call-центра/кураторов. Поэтому от такого формата работы мы быстро отказались, так как в случае с интеграцией с CRM системой - он бесполезен.
Второй вариант реализации сторонней связки, который предлагает нам IDENT - это доступ к HTTP/HTTPS серверам. Он рекомендуется, если требуемые серверы, которые мы хотим подключить к IDENT, размещаются не в локальной сети клиники.
Второй вариант реализации сторонней связки, который предлагает нам IDENT - это доступ к HTTP/HTTPS серверам. Он рекомендуется, если требуемые серверы, которые мы хотим подключить к IDENT, размещаются не в локальной сети клиники.
Подробные требования для такого варианта реализации перечислены здесь.
HTTP запросы - это и есть WEB API (Application Programming Interface). То есть это готовые шаблоны кода запросов, которые могут быть в формате GET, когда мы запрашиваем какие-то данные, и POST, когда мы что-то отправляем во внешний мир. И получается, что теоретически у IDENT есть API, но оно настолько микроскопическое и ограниченное по функционалу (в сравнении с общим функционалом МИС IDENT), что фактически полноценным API его назвать можно с большим трудом.
Получается, что такой формат реализации связки также не дает нам возможности забрать из МИС IDENT необходимый перечень информации, потому что объем данных, который мы можем получить через HTTP/HTTPS (с помощью GET и POST запросов у IDENT) сильно ограничен.
По сути, это всё, что дает нам сделать IDENT в плане внешних интеграций. Получение и передача другой информации в IDENT технически не предусмотрена! Поэтому мы никак не можем сделать эффективную интеграцию в таком формате, чтобы нужные нам данные передавались из сторонней системы в МИС IDENT.
Получается, что такой формат реализации связки также не дает нам возможности забрать из МИС IDENT необходимый перечень информации, потому что объем данных, который мы можем получить через HTTP/HTTPS (с помощью GET и POST запросов у IDENT) сильно ограничен.
По сути, это всё, что дает нам сделать IDENT в плане внешних интеграций. Получение и передача другой информации в IDENT технически не предусмотрена! Поэтому мы никак не можем сделать эффективную интеграцию в таком формате, чтобы нужные нам данные передавались из сторонней системы в МИС IDENT.
Оптимальный вариант работы с IDENT
Из всего описанного выше мы можем сделать вывод, что единственный подходящий вариант для полноценного обмена данными с IDENT, но к сожалению не регламентированный в базе знаний IDENT - это вариант с запросом данных напрямую из БД IDENT, так как регламентированные возможности для интеграции с IDENT через запрос и отправку данных у сторонних СУБД и через HTTP/HTTPS запросы - существенно ограничены.
В итоге, вы должны принять тот факт, что сотрудникам в любом случае придется работать в двух системах! Но при этом, в случае подключения напрямую к БД IDENT, сотрудникам не придется делать двойную работу и дублировать одну и ту же информацию в двух системах. Обрабатывать заявки специалисты будут в amoCRM, а записывать пациентов на прием уже в МИС IDENT. Затем интеграция забирает из БД IDENT необходимую информацию о записи пациента на приём и передаёт ее в amoCRM для дальнейшей работы администратора/оператора call-центра/куратора с пациентом в CRM системе.
В итоге, вы должны принять тот факт, что сотрудникам в любом случае придется работать в двух системах! Но при этом, в случае подключения напрямую к БД IDENT, сотрудникам не придется делать двойную работу и дублировать одну и ту же информацию в двух системах. Обрабатывать заявки специалисты будут в amoCRM, а записывать пациентов на прием уже в МИС IDENT. Затем интеграция забирает из БД IDENT необходимую информацию о записи пациента на приём и передаёт ее в amoCRM для дальнейшей работы администратора/оператора call-центра/куратора с пациентом в CRM системе.
Еще раз повторимся, передача данных из amoCRM в МИС IDENT возможна, но сильно ограничена самим IDENT и фактически бессмысленна и еще больше усложняет работу сотрудников, поэтому ни о какой двусторонней связке или передаче данных из amoCRM в IDENT в данном случае не может идти речи.
Для прямого подключения к БД IDENT нам необходимы данные от пользователя этой БД. Важно: это НЕ пользователь приложения IDENT, а пользователь именно базы данных IDENT. Их важно не путать. Чтобы получить доступ к БД IDENT, - необходимо заполнить заявление на предоставление доступа к БД и отправить его IDENT. Представители IDENT предоставляют доступы от пользователя БД IDENT только с правами на чтение, что даёт возможность только просматривать информацию в БД, но не передавать и записывать её в БД. Только так мы можем действительно получить какую-то детальную информацию из IDENT и в автоматическом режиме передавать ее в amoCRM, чтобы сотрудники видели всё, что происходит с пациентом после его записи на прием.
И такой информации наша текущая связка передает, действительно, достаточно много, чтобы увидеть полную картину по пациенту.
Для прямого подключения к БД IDENT нам необходимы данные от пользователя этой БД. Важно: это НЕ пользователь приложения IDENT, а пользователь именно базы данных IDENT. Их важно не путать. Чтобы получить доступ к БД IDENT, - необходимо заполнить заявление на предоставление доступа к БД и отправить его IDENT. Представители IDENT предоставляют доступы от пользователя БД IDENT только с правами на чтение, что даёт возможность только просматривать информацию в БД, но не передавать и записывать её в БД. Только так мы можем действительно получить какую-то детальную информацию из IDENT и в автоматическом режиме передавать ее в amoCRM, чтобы сотрудники видели всё, что происходит с пациентом после его записи на прием.
И такой информации наша текущая связка передает, действительно, достаточно много, чтобы увидеть полную картину по пациенту.
Помимо передачи данных в поля, также дополнительно синхронизируются статусы приёмов: будущий прием, отменён, перенесён, посетил.
Вопросы для проверки грамотности подрядчика по теме интеграции между amoCRM и IDENT
Мы подготовили для вас ряд вопросов, которые вы можете задать компании-подрядчику, чтобы понять действительно ли она разбирается в технических особенностях и ограничениях связки между amoCRM и МИС IDENT и сможет корректно настроить вам данную интеграцию.
Данные вопросы - это лишь малая часть нюансов и подводных камней, с которыми вам предстоит столкнуться при реализации интеграции. Это лишь 5% от всего того, что уже учтено и реализовано в нашей готовой связке, которую мы дорабатываем и улучшаем на протяжении 3-ех лет и с которой работают уже более 75 стоматологий по всей России.
Данные вопросы - это лишь малая часть нюансов и подводных камней, с которыми вам предстоит столкнуться при реализации интеграции. Это лишь 5% от всего того, что уже учтено и реализовано в нашей готовой связке, которую мы дорабатываем и улучшаем на протяжении 3-ех лет и с которой работают уже более 75 стоматологий по всей России.
ОТВЕТ: Теоретически да, обмен данными может быть организован в обе стороны, но… Количество данных, которые могут быть переданы из внешних структур, платформ и сервисов в МИС IDENT, - сильно ограничено.
Из внешних источников в МИС IDENT могут быть частично переданы данные по звонкам из телефонии (дата и время вызова, номер телефона, время ожидания ответа, продолжительность разговора и др.), данные по заявкам с медицинских сайтов-агрегаторов (ID записи, дата создания заявки, номер телефона, email, ФИО, желаемое время начала приема, желаемый специалист, ID желаемого специалиста и др.). Но такие новые звонки и заявки попадают в IDENT в виде заявок, которые специалисты еще должны обработать, заполнить часть информации (дату приема, время приема, ФИО специалиста), а затем сохранить эту информацию и подтвердить запись. То есть это требует дополнительных время и трудозатрат от администраторов/операторов call-центра/кураторов. И если мы говорим про связку между МИС IDENT и amoCRM, когда данные о записи фиксируются в amoCRM, а потом частично передаются в МИС IDENT, где сотруднику повторно приходится обрабатывать этого же клиента и записывать его на прием уже в МИС, то это просто бессмысленно! Администратор/оператор call-центра/куратор делает двойную работу и еще больше погружается в эту рутину. Задача связки между двумя системами облегчить сотрудникам работу, а не наоборот.
Что касается передачи данных из МИС IDENT во внешние источники, то системой предусмотрена и подробно описана в базе знаний передача данных об онлайн-расписании.
Но дополнительно есть нерегламентированная возможность по забору данных напрямую из БД IDENT с помощью запроса пользователя с правами только на чтение. Подключившись к базе данных мы фактически можем забрать любую информацию из IDENT, которая нам необходима! Но главный нюанс кроется в том, что какой-то документации, описывающей структуру базы данных IDENT, не существует! Эта информация скрыта. И получается, что мы вслепую методом проб и ошибок находим нужные нам данные в этой БД, предполагая, что это именно те таблицы и те данные, которые нам нужны. Это сильно усложняет нам работу и удлиняет процесс забора данных.
Из внешних источников в МИС IDENT могут быть частично переданы данные по звонкам из телефонии (дата и время вызова, номер телефона, время ожидания ответа, продолжительность разговора и др.), данные по заявкам с медицинских сайтов-агрегаторов (ID записи, дата создания заявки, номер телефона, email, ФИО, желаемое время начала приема, желаемый специалист, ID желаемого специалиста и др.). Но такие новые звонки и заявки попадают в IDENT в виде заявок, которые специалисты еще должны обработать, заполнить часть информации (дату приема, время приема, ФИО специалиста), а затем сохранить эту информацию и подтвердить запись. То есть это требует дополнительных время и трудозатрат от администраторов/операторов call-центра/кураторов. И если мы говорим про связку между МИС IDENT и amoCRM, когда данные о записи фиксируются в amoCRM, а потом частично передаются в МИС IDENT, где сотруднику повторно приходится обрабатывать этого же клиента и записывать его на прием уже в МИС, то это просто бессмысленно! Администратор/оператор call-центра/куратор делает двойную работу и еще больше погружается в эту рутину. Задача связки между двумя системами облегчить сотрудникам работу, а не наоборот.
Что касается передачи данных из МИС IDENT во внешние источники, то системой предусмотрена и подробно описана в базе знаний передача данных об онлайн-расписании.
Но дополнительно есть нерегламентированная возможность по забору данных напрямую из БД IDENT с помощью запроса пользователя с правами только на чтение. Подключившись к базе данных мы фактически можем забрать любую информацию из IDENT, которая нам необходима! Но главный нюанс кроется в том, что какой-то документации, описывающей структуру базы данных IDENT, не существует! Эта информация скрыта. И получается, что мы вслепую методом проб и ошибок находим нужные нам данные в этой БД, предполагая, что это именно те таблицы и те данные, которые нам нужны. Это сильно усложняет нам работу и удлиняет процесс забора данных.
ОТВЕТ: При реализации кастомной связки между IDENT и amoCRM и получении прямого доступа к базе данных IDENT, - важно, чтобы непрерывно работала именно база данных IDENT и компьютер, на котором она установлена. Если они будут работать, то и связка в онлайн-режиме 24/7 будет иметь возможность забирать все необходимые данные.
ОТВЕТ: Чтобы получить доступ к БД IDENT с правами на чтение вам необходимо:
- Заполнить заявление на предоставление доступа к базе данных IDENT от имени директора клиники. На заявлении нужно поставить подпись генерального директора клиники и юридически заверенную печать.
- Распечатать и отсканировать или сфотографировать заявление и отправить его в техподдержку IDENT по адресу support@ident-it.ru с общей почты клиники или с личной почты директора.
- Получить доступ от пользователя с правами только на чтение и подключаться в рамках локальной сети к самой базе данных IDENT.
ОТВЕТ: Данные не пропадут, так как они в любом случае останутся в базе данных IDENT.
Если компьютер, на котором установлена БД IDENT, выключился, или на нем отключился интернет, то в данном случае перестает работать БД IDENT и временно останавливаются все обновления и передача данных. Когда соединение будет вновь восстановлено, то наша связка, разработанная компанией REON, с помощью соответствующих временных штампов увидит, когда была сделана последняя успешная синхронизация или передача данных из IDENT в amoCRM, и с этой точной даты и времени запустит передачу данных.
Это обеспечивается специальным модулем, который был разработан и интегрирован в связку между IDENT и amoCRM, и который обеспечивает вот такую отказоустойчивость и консистентность данных в двух системах. То есть эта информация будет в любом случае передана в CRM систему, но после включения ПК и восстановления интернет соединения.
Если компьютер, на котором установлена БД IDENT, выключился, или на нем отключился интернет, то в данном случае перестает работать БД IDENT и временно останавливаются все обновления и передача данных. Когда соединение будет вновь восстановлено, то наша связка, разработанная компанией REON, с помощью соответствующих временных штампов увидит, когда была сделана последняя успешная синхронизация или передача данных из IDENT в amoCRM, и с этой точной даты и времени запустит передачу данных.
Это обеспечивается специальным модулем, который был разработан и интегрирован в связку между IDENT и amoCRM, и который обеспечивает вот такую отказоустойчивость и консистентность данных в двух системах. То есть эта информация будет в любом случае передана в CRM систему, но после включения ПК и восстановления интернет соединения.
ОТВЕТ: Частая ошибка, когда клиенты, обращаясь за связкой amoCRM с IDENT, полагают, что администраторам/операторам call-центра/кураторам больше не придется работать в МИС IDENT и всю работу они будут вести только в amoCRM. К сожалению, это не так.
Сотрудникам предстоит работать как в amoCRM, так и в МИС IDENT, просто эта работа будет разной. В amoCRM специалисты будут обрабатывать весь входящий трафик, вести всю коммуникацию с клиентами, проводить квалификации и консультации, но запись на прием они будут производить сразу в IDENT. А далее уже сама связка заберет данные о записи пациента из МИС IDENT и передаст их в CRM систему, где сотрудник уже продолжит дальнейшую работу с пациентом. Но при этом специалисты не будут делать двойную работу и дублировать одну и ту же информацию параллельно в две системы, как раз-таки это за них сделает наша связка.
Сотрудникам предстоит работать как в amoCRM, так и в МИС IDENT, просто эта работа будет разной. В amoCRM специалисты будут обрабатывать весь входящий трафик, вести всю коммуникацию с клиентами, проводить квалификации и консультации, но запись на прием они будут производить сразу в IDENT. А далее уже сама связка заберет данные о записи пациента из МИС IDENT и передаст их в CRM систему, где сотрудник уже продолжит дальнейшую работу с пациентом. Но при этом специалисты не будут делать двойную работу и дублировать одну и ту же информацию параллельно в две системы, как раз-таки это за них сделает наша связка.
ОТВЕТ: При первом запуске связки будут полностью синхронизированы все пациенты и карточки контактов между IDENT и amoCRM, а также будут переданы все будущие приемы из IDENT в amoCRM. Стартовая синхронизация по времени может занять от нескольких часов до нескольких дней, всё зависит от объема накопленной информации в вашей БД IDENT.
В дальнейшем, наша связка настроена таким образом, что синхронизация данных будет производиться в рамках 10-40 секунд, и данные в amoCRM будут обновляться с таким интервалом. Задержка данных может произойти в том случае, если будут проблемы с подключением интернета на компьютере, на котором установлена база данных IDENT.
Доступность amoCRM контролируется самой CRM системой, что обеспечивает непрерывную работу 24/7. Поэтому каких-либо проблем по передаче данных со стороны amoCRM быть не должно.
В дальнейшем, наша связка настроена таким образом, что синхронизация данных будет производиться в рамках 10-40 секунд, и данные в amoCRM будут обновляться с таким интервалом. Задержка данных может произойти в том случае, если будут проблемы с подключением интернета на компьютере, на котором установлена база данных IDENT.
Доступность amoCRM контролируется самой CRM системой, что обеспечивает непрерывную работу 24/7. Поэтому каких-либо проблем по передаче данных со стороны amoCRM быть не должно.
ОТВЕТ: Очень важным вопросом при интеграции является работа с дублями. Важно, чтобы связка не создавала в amoCRM дублирующие сущности: дубли карточек контактов и карточек сделок. Для этого внутри связки должна быть реализована трехступенчатая идентификация для поиска информации в amoCRM.
Такими идентификаторами при поиске пациентов являются номер телефона и ID пациента, а при поиске приема, - добавляется еще ID приема.
Связка с IDENT должна найти соответствующую карточку сделки по определенной логике и алгоритмам, при этом не создав дубль (иначе в вашей CRM системе будут тысячи дублей и вы просто не сможете корректно работать), и далее перенести карточку сделки этого пациента на этап “Записан на прием”. То есть произойдет автоматическое перемещение карточки сделки по воронке продаж в amoCRM. Это тот функционал, который уже реализован в нашей связке и корректно работает.
Такими идентификаторами при поиске пациентов являются номер телефона и ID пациента, а при поиске приема, - добавляется еще ID приема.
Связка с IDENT должна найти соответствующую карточку сделки по определенной логике и алгоритмам, при этом не создав дубль (иначе в вашей CRM системе будут тысячи дублей и вы просто не сможете корректно работать), и далее перенести карточку сделки этого пациента на этап “Записан на прием”. То есть произойдет автоматическое перемещение карточки сделки по воронке продаж в amoCRM. Это тот функционал, который уже реализован в нашей связке и корректно работает.
ОТВЕТ: карточка пациента в IDENT равна карточке контакта в amoCRM, а карточка записи на прием в IDENT равна карточке сделки в amoCRM. Поэтому если у пациента несколько записей на прием, то по каждой записи на прием в IDENT должна быть создана новая карточка сделки в amoCRM. Нельзя фиксировать в одну карточку сделки в amoCRM информацию обо всех приемах и записях из IDENT! Это ошибка!
Если у пациента несколько записей на прием в IDENT, то в amoCRM появится несколько карточек сделок, по каждой из которой будет отдельно вестись работа и отдельно фиксироваться информация о враче, дате приема, оказываемой услуге, сумме оплат и тд.
Если у пациента несколько записей на прием в IDENT, то в amoCRM появится несколько карточек сделок, по каждой из которой будет отдельно вестись работа и отдельно фиксироваться информация о враче, дате приема, оказываемой услуге, сумме оплат и тд.
ОТВЕТ: Так как это разные пациенты, то даже если у них один номер телефона, то информация о них должна быть сохранена в разных карточках контакта.
Идентификация в этом случае будет производиться по уникальному ID номеру пациента в IDENT, при этом номера телефонов у этих контактов будут одинаковые. В рамках amoCRM эти сущности будут являться дублями и система будет предлагать их склеить, но делать этого не нужно, так как это будет некорректно в рамках разных пациентов.
В целом данная ситуация является некорректной не только для amoCRM, но и для IDENT, потому что у каждого пациента должен быть свой номер телефона. При этом мы понимаем, что есть определенные обстоятельства и уникальная логика работы в стоматологиях, которая предполагает наличие карточек пациентов, у которых один и тот же номер телефона. Поэтому данный нюанс учтен в нашей связке и по каждому пациенту будет создана отдельная карточка контакта.
Идентификация в этом случае будет производиться по уникальному ID номеру пациента в IDENT, при этом номера телефонов у этих контактов будут одинаковые. В рамках amoCRM эти сущности будут являться дублями и система будет предлагать их склеить, но делать этого не нужно, так как это будет некорректно в рамках разных пациентов.
В целом данная ситуация является некорректной не только для amoCRM, но и для IDENT, потому что у каждого пациента должен быть свой номер телефона. При этом мы понимаем, что есть определенные обстоятельства и уникальная логика работы в стоматологиях, которая предполагает наличие карточек пациентов, у которых один и тот же номер телефона. Поэтому данный нюанс учтен в нашей связке и по каждому пациенту будет создана отдельная карточка контакта.
ОТВЕТ: Да, можно передавать информацию о задачах из IDENT в amoCRM и непрерывно актуализировать статусы задачи в CRM системе, но опять-таки есть нюанс… Когда мы передаем задачи из МИС IDENT в amoCRM, то мы предполагаем, что сотрудники будут работать с этими задачами в рамках amoCRM, то есть выполнять и отписываться по ним они будут в рамках CRM системы. И тут возникает проблема, что отписавшись по задаче и закрыв ее в amoCRM, - задача в МИС IDENT не закроется. Обмен такими данными в противоположную сторону из amoCRM в IDENT технически невозможен, поэтому как-то передать информацию о том, что мы выполнили задачу, - мы не можем.
И получается, что сотруднику нужно выполнить задачу в amoCRM, а затем перейти в IDENT и выполнить эту задачу еще раз в МИС, что опять-таки будет только усложнять и удваивать работу. Поэтому логически нет смысла передавать задачи из МИС IDENT в amoCRM.
И получается, что сотруднику нужно выполнить задачу в amoCRM, а затем перейти в IDENT и выполнить эту задачу еще раз в МИС, что опять-таки будет только усложнять и удваивать работу. Поэтому логически нет смысла передавать задачи из МИС IDENT в amoCRM.
В итоге, мы рассмотрели с вами всего 10 вопросов, касаемых логики работы связки… Это лишь маленькая часть тех подводных камней, с которыми вам предстоит столкнуться и предстоит решить при реализации связки между МИС IDENT и amoCRM.
Помимо этих вопросов вы можете также задать целый ряд уточняющих вопросов. Например таких как: Что произойдет с карточкой Сделки в amoCRM после отмены Приёма? Что произойдет с карточкой Сделки в amoCRM после переноса приёма? Какая денежная сумма фиксируется в поле бюджет в карточке Сделка в amoCRM? Как учитывается скидка, авансовая и дебиторская задолженность пациента в карточке Сделка в amoCRM? Как и где фиксируются данные о представителях в amoCRM? Как и где фиксируются данные о профосмотрах в amoCRM? Есть ли фиксация и разграничение работы с пациентами из разных филиалов в amoCRM?
Алексей Яновский
Руководитель компании REON
Связка amoCRM & IDENT от REON
Со всеми этими подводными камнями и нюансами мы уже столкнулись и на 99% их учли и решили в рамках работы нашей связки.
А вот учтены ли все эти нюансы интеграции у других подрядчиков? Вообще знакомы ли они с ними? Или они будут собирать подводные камни вместе с вами за ваши деньги? И тогда ваша связка, разработанная ими, будет носить весьма сырой характер… Потребуется колоссальное количество времени и денег для постоянной ее доработки и улучшения. У нашей компании REON ушло порядка 3 лет и более 3,5 миллионов рублей для разработки той актуальной версии связки между amoCRM и МИС IDENT, которая сейчас подключается нашим клиентам. Поэтому зачем с нуля за свои же деньги изобретать велосипед, если можно установить связку, которая проверена временем и другими компаниями стоматологиями.
Запишитесь на бесплатную консультацию с нашим специалистом и мы расскажем, как оптимизировать работу внутри вашей клиники!
Меню:
контакты:
115280, г. Москва, ул. Ленинская Слобода, 26с28, офис 306
ИНН 6164144806 КПП 616401001 ОГРН 1246100016524
ООО "РЕОН"
ООО "РЕОН"
Услуги:
344002, г. Ростов-на-Дону,
ул. Социалистическая 74, офис 203-2
ул. Социалистическая 74, офис 203-2