Мы отправили запрос в службу поддержки ИИ. Он восстановил интеграцию и замкнул цикл.
Как Клод Код и APIANT превратили сложную ошибку синхронизации нескольких платежей в проверенное решение, которое было подтверждено человеком только в самом конце.

Как Клод Код и APIANT превратили сложную ошибку синхронизации нескольких платежей в проверенное решение, которое было подтверждено человеком только в самом конце.
Этот экземпляр взят из CRMConnectAPIANT — это готовое решение для интеграции Mindbody и HubSpot, обеспечивающее синхронизацию данных о клиентах, дедупликацию и сопоставление полей, позволяя маркетинговой команде работать с реальными данными, а не с устаревшими экспортированными данными. В данном случае речь идёт о части, которая преобразует продажи из Mindbody в сделки в HubSpot, благодаря чему доход автоматически поступает в CRM с правильной суммой, привязанной к нужному клиенту.
Клиент заплатил около 8400 долларов на стойке регистрации. В CRM-системе сумма сделки составляла 400 долларов. Никаких ошибок не возникло, ничего не выглядело сломанным, и большинство продаж синхронизировались нормально. Эта сделка незаметно потеряла большую часть своей стоимости где-то между Mindbody и HubSpot.
Это самые худшие виды ошибок: те, что скрываются в 2% транзакций, которые немного необычны. Мы передали эту задачу искусственному интеллекту и позволили ему управлять всем процессом, от диагностики до проверенного решения и ответа клиенту. Вот как это происходило.
Билет
В редакцию обратились представители небольшой фитнес-студии с небольшой, но досадной загадкой. Большая часть их продаж беспрепятственно проходила через Mindbody в HubSpot. Но с этой одной сделкой возникли проблемы.
Виновником оказалась ситуация, когда оплата производилась несколькими способами. Если разделить платеж между картой и балансом счета, старая система синхронизации считывала данные из отчета, который не включал все способы оплаты. В результате сделка прошла с оплатой лишь части фактически уплаченной суммы.
Почему это обычно медленное и болезненное решение
Подобные ошибки обычно отнимают дни у разработчиков. Кому-то приходится перестраивать работу интеграции, выяснять, какой из нескольких путей синхронизации неисправен, изменять логику, не нарушая уже работающие пути, а затем тестировать это на реальной системе, в которую действительно сложно что-либо вмешать. Программное обеспечение для точек продаж не предоставляет вам песочницу с кнопкой «совершить странную продажу с раздельным платежом».
Поэтому процесс обычно затягивается. Клиент ждёт. Исправление рискованно. Все немного нервничают, когда дело доходит до работы над интеграцией.
Вместо этого мы передали это искусственному интеллекту.

Мы передали задачу Клоду Коду, работающему на APIANT, и позволили ему работать. Не «предложить фрагмент кода». А действительно работать: прочитать интеграцию, понять её, внести изменения, протестировать на реальном аккаунте Mindbody и сообщить о результатах. Вот что получилось, без участия человека, написавшего хоть одну строчку кода.
Это позволило выявить истинную причину. Проблема была выявлена по трем отдельным причинам, скрывающимся за одним симптомом: синхронизация считывала данные из отчета, в котором отсутствовали некоторые типы платежей, продажи нескольких товаров учитывались некорректно, и несколько продаж могли совпадать по одному и тому же идентификатору.
Интеграция была восстановлена корректно. Вместо быстрого исправления ошибок, логику обработки сделок переработали в один общий компонент, используемый как для мгновенной синхронизации (срабатывает в момент совершения продажи), так и для ночной синхронизации. Та же логика, два триггера, больше нет расхождений между ними. Обе системы перешли на более полный источник данных, который фактически включает в себя все платежи, включая остатки на счетах и балансы участников.
Это позволило ускорить процесс в больших масштабах. Добавлено кэширование, чтобы ночная задача не выполняла повторно медленные запросы к тысячам прошлых продаж. Первый проход создает кэш; каждый последующий проход пропускает дорогостоящий поиск.
Это добавило ту деталь, которую хотел клиент. Теперь для каждой сделки регистрируется использованный способ оплаты, поэтому студия может с первого взгляда увидеть, как была произведена оплата.
Затем его протестировали на реальной системе.

Эта часть до сих пор немного напоминает научную фантастику.
Искусственный интеллект открыл в браузере реальную кассу Mindbody и самостоятельно провел тестовые продажи. Один товар оплачен в одну сторону. Один товар разделен на два платежа. Несколько товаров оплачены одним платежом. Несколько товаров разделены на несколько платежей. Посетитель без записи о клиенте. Он прошел через кассу, как это сделал бы сотрудник.
Затем система отслеживала каждую продажу, проходящую через интеграцию, и построчно считывала результаты. Было ли создано правильное количество сделок? Соответствовали ли суммы общей сумме продажи? Отобразился ли способ оплаты? Приводила ли синхронизация дважды к созданию дубликатов, или система правильно распознала, что продажа уже была обработана?
Проверка прошла во всех отделениях. Суммы совпали. Дубликатов нет. Способы оплаты сработали.
Оно осознало свою ошибку

В процессе работы одно из внесенных изменений привело к небольшой регрессии. Новое поле было неправильно подключено, и это незаметно нарушило процесс создания новых сделок.
Искусственный интеллект это заметил, потому что он считывал данные о реальном исполнении сделки, а не предполагал, что его работа верна. Он нашел точную причину, исправил неполадки, повторно запустил реальную неудачную сделку и подтвердил, что исправление дало правильный результат, документируя весь процесс на каждом этапе.
В этом и заключается разница между созданием кода и владением результатом.
Это позволило замкнуть цикл взаимодействия с клиентом.
После подтверждения исправления ИИ написал клиенту ответ простым языком: что происходит, почему сумма выглядела неправильно, что изменится сейчас, и заверил, что все предыдущие продажи исправятся автоматически при следующей синхронизации. Он подготовил это сообщение к отправке в рамках заявки.
Человек прочитал это, согласился и отправил. Человек также дал окончательное разрешение на публикацию изменений в продакшене. Это сделано намеренно. Искусственный интеллект выполняет тяжелую, точную и неустанную работу. Люди же контролируют два решения, которые всегда должны приниматься человеком: что мы говорим клиенту и что запускается в работу.
Одно решение для каждого клиента
Вот что важно, если вы занимаетесь разработкой интеграций профессионально. Это не был разовый скрипт, прикрепленный к одному аккаунту. Синхронизация Mindbody с HubSpot — это готовый продукт. API-приложение: одна интеграция, созданная и поддерживаемая в одном месте, работающая для каждого клиента, который ее использует. Поэтому, когда ИИ перестроил логику сделок, он исправил проблему не только в этой одной студии. Он устранил тот же пробел в раздельной оплате для всех пользователей этой интеграции, и каждый новый клиент получает исправленную версию с первого дня.
Именно такую модель системной интеграции постоянно запрашивают интеграторы. Создайте решение один раз, продавайте его многократно и улучшайте в одном месте. Подобное решение повышает качество продукта для всей базы пользователей одновременно, что и превращает готовую интеграцию в реальный актив, приносящий регулярный доход, вместо кучи индивидуальной работы для каждого клиента, которая становится все более уязвимой по мере роста.
Почему APIANT делает это возможным
Искусственный интеллект может управлять только тем, что видит и может потрогать. Большинство интеграционных платформ представляют собой «чёрный ящик», поэтому ИИ вынужден генерировать предложения извне.
APIANT построен наоборот. Каждая интеграция состоит из частей, которые ИИ может реально проверять, редактировать и запускать: автоматизация, общие подпрограммы, сопоставление полей, история выполнения в реальном времени, кэшированные значения. ИИ может изменить один элемент, запустить его, точно прочитать, что произошло на каждом шаге, и внести корректировки. В сочетании с управлением исходной системой через браузер, он может тестировать на основе реальных данных, а не гадать.
Именно это сочетание позволило превратить один сложный реальный тикет в полноценный, проверенный рефакторинг.
Главный вывод
Это была не просто игровая проблема. Это была незаметная, многофакторная ошибка в процессе интеграции двух серьезных систем, обычно приводящая к нервозности инженера и затишью на неделе.
Искусственный интеллект взялся за весь процесс от начала до конца. Он выявил истинную причину, правильно перестроил интеграцию, протестировал каждый путь на реальной точке продаж, обнаружил и исправил собственную ошибку, а также подготовил ответ клиенту. Люди вмешивались только для утверждения сообщения и развертывания.
Вот куда всё это движется. Не ИИ, который пишет за вас немного кода, а ИИ, который берёт сложную, конкретную проблему и доводит её до рабочего, протестированного решения на платформе, созданной именно для этого. Если у вас есть почти правильные интеграции или ошибки, которые проявляются только в тех 2% случаев, то именно так начинает выглядеть их решение.


