Lindy AI vs MultiOn 2026: no-code сотрудник против API-агента

Услышали от коллеги «AI-агент — попробуй Lindy или MultiOn» и не поняли, о чём речь. На деле это два продукта из соседних миров: их сравнивают, потому что оба в категории агентов, а не потому что они конкурируют лоб в лоб.

Lindy AI — no-code платформа для бизнес-автоматизации. Пользователь собирает агента («Lindy») из блоков: триггер, действие, условие. Триггер — новый email, встреча в календаре, вебхук, сообщение в Slack. Действие — отправить письмо, создать запись в HubSpot, ответить в чате, назначить встречу. LLM под капотом выбирается платформой автоматически — по официальной позиции сервиса это GPT-4o или Claude, но какой именно на конкретной задаче, пользователь не решает и не видит. Точная модельная политика в открытые источники не выведена — это data gap самого производителя.

MultiOn устроен наоборот. Это API для веб-автоматизации, основанный Div Garg. Разработчик пишет несколько строк на Python или JavaScript, вызывает create, step, retrieve и передаёт задачу вида «зайди на сайт X, залогинься моими куками, скачай отчёт за март». MultiOn поднимает managed-браузер у себя в облаке, LLM-слой парсит страницу и выполняет клики. Точная модель под капотом тоже не публикуется — компания фиксирует это как политику. На выходе разработчик получает результат в удобном формате и встраивает его в свой бэкенд.

Из таблицы уже видно главное: Lindy живёт в почтовом ящике и CRM SMB-команды, MultiOn — в коде разработчика. Пересечение возникает только там, где один и тот же человек одновременно и оператор процесса, и его программист, — а такое сочетание встречается редко.

По официальной концепции Lindy — «AI employee»: не инструмент, а виртуальный сотрудник, которому ставят задачу на естественном языке и который дальше сам понимает контекст. MultiOn — инфраструктура: разработчик получает готовый managed-браузер и не поднимает Playwright или Selenium сам. Оба используют LLM, но на разных уровнях стека — Lindy оркеструет действия в SaaS-сервисах, MultiOn оркеструет клики на веб-странице. Пытаться их «сравнить в лоб» — то же самое, что сравнивать Zapier и Playwright: формально оба «автоматизируют», но лежат на разных полках у здравомыслящего инженера.

У Lindy автономность встроена в саму концепцию продукта. Собрали агента, подключили Gmail, задали правила эскалации — дальше он работает 24/7 без вас. Если Lindy не уверен в ответе, есть механизм escalation: агент останавливается и передаёт задачу человеку. Перед запуском в prod можно прогнать сценарии через testing/simulation — это отдельная фича, которую компания выделяет отдельно. Плюс концепция multi-agent collaboration: один Lindy делегирует задачу другому Lindy, и получается горизонтально масштабируемый workflow, где вы вообще не участвуете в передаче.

MultiOn работает не «в фоне», а «по запросу». Разработчик явно вызывает create, потом серию step, потом retrieve — и на каждый шаг может посмотреть скриншот текущего состояния браузера. Есть отдельный step-by-step mode — компания позиционирует его как удобство для отладки. То есть автономности «поставил и забыл» тут по дизайну нет: агент выполнил задачу — вернул результат — сессия завершилась. Хотите повторить — вызывайте снова.

На нашем опыте это ключевое различие психологии продукта. Lindy рассчитан на пользователя, который не хочет присутствовать при исполнении задачи, — он хочет проснуться утром и увидеть, что 40 писем уже классифицированы. MultiOn рассчитан на разработчика, который встраивает шаг «зайти на сайт и извлечь данные» в свой пайплайн, — и хочет ровно тот момент, когда этот шаг случается, а не «в фоне». Обе модели легитимны, но выбирать между ними стоит на уровне «что вам нужно от агента», а не «какой из них лучше».

Нужно заходить на чужой сайт, кликать по кнопкам и извлекать данные — здесь картина резко асимметричная. Один сервис делает это по определению, второй в принципе не задуман для такого.

MultiOn — это в чистом виде browser-use агент. Его архитектура прямо такая: managed browser в облаке, LLM-слой понимает вёрстку страницы и принимает решения, у разработчика есть базовый набор действий — goto, click, type, scroll, back, forward. Отдельно есть extract для извлечения структурированных данных со страницы через natural-language-запрос и screenshot для получения текущего состояния браузера. Разработчику не нужно писать XPath или CSS-селекторы — задача формулируется словами, а сервис сам решает, куда кликать.

У Lindy этого нет вообще. В её списке возможностей нет строки «browser automation», «computer use» или «навигация по сайтам». Всё, что Lindy умеет с внешним миром, — это работать через официальные интеграции: Gmail через API Gmail, HubSpot через API HubSpot, Slack через Slack API. Если у сервиса нет API — Lindy до него не дойдёт. Заходить на сайт-конкурента, логиниться под своими куками и что-то забирать — не её задача. Технически это можно попробовать сделать через Zapier-мост или вебхук, но это костыль, а не фича, о которой пишет производитель.

Отдельно про надёжность. Компания MultiOn сама фиксирует, что на динамических сайтах, capcha и нестандартном UI надёжность средняя — публичных бенчмарков качества нет. То есть даже там, где браузерная автоматизация — единственный ответ, ожидать 100% успеха на любом сайте не стоит. Это нормально для всего класса browser-use агентов на 2025 год, но важно понимать: MultiOn побеждает Lindy в этой подтеме не потому, что он идеальный, а потому, что Lindy тут вообще не играет.

Здесь картина зеркальная предыдущей подтеме — теперь беспомощен уже MultiOn. Workflow-автоматизация с готовыми коннекторами к Gmail и CRM — это ровно то, ради чего делали Lindy.

У Lindy официально заявлены глубокие интеграции с рабочим стеком SMB-команды: Gmail и Outlook на стороне почты, Google Calendar и Outlook Calendar на стороне расписания, Zoom и Google Meet на стороне звонков, HubSpot и Salesforce на стороне CRM, Slack и WhatsApp Business на стороне мессенджеров, Notion, Linear и Asana на стороне задач. Плюс Zapier и вебхуки для всего остального. Список активно расширяется — производитель прямо помечает это как data gap с оговоркой «интеграции добавлялись активно» на дату проверки досье, август 2025.

MultiOn интегрирован только с одним «приложением» — с браузером. Никаких коннекторов к Gmail, HubSpot или Slack у него нет и по концепции не должно быть: это API-инфраструктура, а не workflow-платформа. Если разработчику нужно, чтобы MultiOn отправил письмо, он делает это отдельным запросом через Gmail API из своего кода — MultiOn тут не помощник. Есть браузерное расширение MultiOn для личного использования, но это про запуск агента из хрома, а не про интеграцию с бизнес-стеком.

Отдельная сильная сторона Lindy — email-first design. Компания подчёркивает, что интеграция с Gmail и Outlook у неё не «на уровне отправить письмо», а на уровне «читать входящие, классифицировать, отвечать в потоке». Для команды из 5–20 человек, где на общий ящик поддержки приходит по 60 писем в день, это качественно другой пакет по сравнению с «настроил фильтр в Gmail». Мы отдельно отмечаем этот пункт как редакция AIRatings — на рынке no-code-агентов такой глубины Gmail-интеграции достигают немногие, и это одна из причин, почему Lindy заметна на HN и Product Hunt.

Российский пользователь в первую очередь спрашивает: «А по-русски он поймёт?» Здесь оба сервиса ведут себя одинаково — по остаточному принципу.

Ни Lindy, ни MultiOn не позиционируются как продукты с оптимизацией под русский язык. В обоих досье прямо зафиксировано, что русский поддерживается только на уровне возможностей нижележащей LLM. У Lindy это GPT-4o или Claude — обе модели уверенно понимают русский на общем уровне, что косвенно даёт агенту способность понять русский промпт и написать русский ответ. Но специальной оптимизации под русские сценарии (русскоязычные email-шаблоны, транслитерация имён из HubSpot, работа с русскими датами и адресами) у Lindy нет. Интерфейс — только английский.

MultiOn находится в такой же ситуации. Компания напрямую пишет: «работает через базовую LLM; русскоязычные сайты теоретически поддерживаются, но не тестировались официально». То есть если вы передадите MultiOn задачу «зайди на wildberries.ru и извлеки цены на модель X», технически он попробует, но никаких гарантий по надёжности парсинга кириллической вёрстки, обработки русских кнопок «Добавить в корзину» или интеракции с российскими CAPTCHA у вас не будет. Публичных бенчмарков на русскоязычных сайтах нет — это data gap, зафиксированный самим сервисом.

Отсюда наша редакционная позиция: обоим сервисам мы ставим по 5/10 — это нейтральная оценка с пометкой «компания не публикует данные по параметру» (см. правило работы с data gap в наших обзорах). Русский там технически работает, но никто из вендоров не берёт на себя ответственность за качество на русскоязычных задачах. Для команды, где переписка с клиентами на русском и объём — сотни писем в неделю, это означает: тестировать нужно на своих реальных задачах, а не полагаться на маркетинг вендора.

Первый вопрос, который клиент задаёт после «а что он умеет?», — «сколько стоит?» Здесь у сервисов принципиально разные подходы к прозрачности.

У Lindy тарифная сетка выведена в открытые источники: Free ($0), Pro (ориентировочно $49.99/мес), Business/Teams (от $99/мес) и Enterprise (custom). Точные цены Pro и Business/Teams на август 2025 в досье помечены как data gap — сервис их периодически меняет, и мы фиксируем это честно, чтобы не подставлять устаревшие цифры. Enterprise-тариф включает SSO, SLA, приоритетную поддержку и кастомные интеграции.

MultiOn выбрал противоположный подход: у него есть Free/Developer с ограниченным числом API-вызовов «для тестирования» — и на этом публичная сетка обрывается. Точные тарифы платных уровней в надёжные источники на август 2025 не выведены. Это самостоятельный минус для сервиса, о котором мы говорим прямо: непрозрачное ценообразование в 2025 году — плохой сигнал для покупателя, особенно в B2B, где часто нужно заложить бюджет заранее.

Что касается совокупной стоимости за год, у Lindy на Pro-тарифе она сейчас составляет порядка $600 при простом умножении $49.99 × 12 — и это грубый ориентир, а не гарантия. Пользователи в отзывах отдельно жалуются, что credits внутри тарифа сгорают быстрее, чем ожидалось, — на сложных задачах фактическая цена может расти. У MultiOn считать TCO пока просто нечем: заложить бюджет на год без обращения в sales-команду невозможно.

Free у Lindy — это ограниченное число задач в месяц (tasks/runs) и доступ к нескольким предустановленным Lindy-шаблонам. Точный лимит задач компания в открытые источники не выводит — data gap. То есть построить своего первого email-агента, подключить Gmail и запустить его на входящие письма можно бесплатно; продолжить работу в промышленном объёме — нельзя, упрёшься в лимит и придётся идти на Pro. Это стандартная freemium-модель «покажи, что работает, потом плати».

Free/Developer у MultiOn устроен под другую аудиторию — разработчика на этапе интеграции. Даётся ограниченное число API-вызовов (сессий), достаточных, чтобы прогнать несколько задач и убедиться, что API отвечает нужным вам образом. Точный лимит на Free — снова data gap. Никакого «делать что-то в проде» на Free-уровне MultiOn не предполагает по концепции: как только вы запустите даже маленький продакшн, лимиты закончатся за часы, а не за дни.

Мы в редакции пробовали оба Free-тарифа как «прогонный» инструмент — оба работают ровно как ожидается: у Lindy проще собрать первого агента (шаблоны), у MultiOn проще проверить свой конкретный сценарий (задача формулируется в одну функцию Python). Но ждать, что на Free вы получите промышленное решение, не стоит ни у одного из вендоров — это trial с бессрочным доступом к прототипу, а не «навсегда бесплатный продукт».

Отдельно про то, что важно только разработчику: можно ли встроить агента в свой продукт. Здесь картина максимально контрастная — один сервис built for API, второй его вообще не даёт.

MultiOn — API-first по своей архитектуре. Основной эндпоинт — https://api.multion.ai, REST-интерфейс с методами create, step, retrieve. Для интеграции доступен официальный Python SDK (устанавливается стандартным pip install multion) и официальный JavaScript-пакет через npm. Есть также браузерное расширение MultiOn — но это отдельный продукт для личного использования, не связанный с production-пайплайном.

У Lindy в списке ограничений досье прямо стоит пункт: «нет API для разработчиков, нельзя строить собственные продукты на Lindy». Это осознанное позиционирование продукта — no-code платформа для оператора, а не SaaS-инфраструктура. Внешние сценарии можно подключать через Zapier или вебхуки, но собственного публичного developer-API у Lindy нет.

Практическое следствие для команды: если вы собираетесь встраивать агента в собственный SaaS-продукт (например, добавить фичу «наш ассистент сходит на портал банка и заберёт выписку»), Lindy отпадает по определению. Вам нужен API — а его тут нет. MultiOn — единственный вариант из двух, кто предоставляет production-грейд developer experience.

Оба сервиса — американские, оба через Stripe. Здесь ответ короткий: без специальных манипуляций российский пользователь не подпишется ни на один из них.

По Lindy: прямой доступ без VPN — статус не подтверждён (data gap), сервис американский, ограничения возможны. Оплата российскими картами не поддерживается — работают через Stripe, а Stripe карты российских банков не принимает с 2022 года. Интерфейс полностью на английском, что для условного SMB-владельца, для которого сервис изначально и делали, — уже блокер (задача автоматизации email на английском платформе на русскоязычной аудитории лишена смысла без билингвы в команде).

По MultiOn картина такая же: прямой доступ не подтверждён (сервис американский, официального подтверждения geo-статуса нет — data gap). Оплата российскими картами тоже не поддерживается. Публичной информации о работе через российские платежные системы нет ни у одного из сервисов — и, судя по общей политике американских AI-стартапов образца 2025 года, ждать её не стоит.

Для российской команды это означает стандартный набор шагов: зарубежная карта, VPN на всякий случай для регистрации, английский интерфейс. Оба сервиса ставят российского пользователя в одинаково неудобное положение — поэтому в этой подтеме мы ставим обоим по 3/10 (плохо, но функция технически доступна для тех, кто прошёл эти три круга). Это не «данные не публикуются, ставим 5/10 нейтрально» — здесь мы видим конкретный минус и оцениваем его как минус.

Компания Lindy отдельно подчёркивает низкую задержку в email-сценариях: агент отвечает практически в реальном времени после получения письма, задержка измеряется секундами. Meeting summary после звонка обычно готов в течение нескольких минут после завершения встречи. Сложные multi-step задачи могут занимать несколько минут — это уже не «мгновенно», но всё ещё быстро для того, что автоматизирует часовую ручную работу.

У MultiOn речь идёт не о полном workflow, а о шаге в браузере. По собственной документации скорость на шаг зависит от загрузки серверов и сложности страницы, обычно — 3–15 секунд. Компания сама признаёт, что надёжность средняя, особенно на динамических сайтах с CAPTCHA или нестандартным UI. Публичных бенчмарков качества нет — это data gap, отмеченный производителем.

Есть и обратная сторона: у Lindy fast-скорость возможна, потому что задача узко-специализированная — «прочитать письмо, классифицировать, ответить по шаблону». У MultiOn каждый шаг — это работа с непредсказуемой веб-страницей, что фундаментально медленнее и менее надёжно. Оценки в этой подтеме отражают этот дисбаланс: Lindy 8/10 (в своей нише отвечает почти мгновенно), MultiOn 6/10 (нормально для класса, но с оговоркой про надёжность самого производителя).

Оба сервиса просят доступ к чувствительным данным — почте, паролям для логина в чужие сайты. Публичной прозрачности по compliance при этом заметно меньше, чем хотелось бы.

У Lindy пользователь при подключении Gmail или Outlook даёт OAuth-доступ, и после этого письма читаются на серверах Lindy — данные хранятся в инфраструктуре компании в США. SOC 2 в досье помечен как заявленный для Enterprise-тарифа, но точный сертификационный статус (SOC 2 Type II, дата аудита, аудитор) в открытые источники не выведен — data gap. Политика обучения моделей на данных пользователей публично не подтверждена — ещё один data gap. Для агента, у которого в руках корпоративная переписка, это серьёзные пробелы прозрачности.

MultiOn работает по своей модели: managed-браузер поднимается у него в облаке, session-данные и cookies уходят на его серверы. Компания официально не рекомендует передавать пароли через API для sensitive-сайтов — это прямая политика безопасности с их страницы. Полная privacy policy в удобной форме на дату проверки досье не была детально проработана — data gap.

Наша позиция: оба сервиса получают 5/10 — это нейтральная оценка «компания не публикует данные по параметру», принятая в наших обзорах для случаев, когда критичная информация недоступна публично (см. §17 SKILL). Это не значит «одинаково хорошо» — это значит «одинаково непрозрачно», и при доступе к корпоративной почте или learn-сессиям такое положение дел мы честно фиксируем как минус самим фактом отсутствия документов.

Категория AI-агентов остаётся одной из самых финансируемых в 2024–2025, но в конкретной паре Lindy и MultiOn обе компании — приватные стартапы без раскрытых деталей раундов. Это фактор риска, о котором стоит говорить прямо.

Lindy AI — венчурный стартап из Сан-Франциско, основан в 2023 году, публичный запуск состоялся в 2024. Точные суммы раундов финансирования в открытые источники на август 2025 не выведены — это data gap, о котором мы честно сообщаем. Точное количество платящих клиентов компания тоже не раскрывает; на сайте есть testimonials от малого и среднего бизнеса, но конкретных цифр по MRR или ARR публично нет.

MultiOn, Inc. — тоже приватная компания из Сан-Франциско. Основатель — Div Garg. По данным TechCrunch и Crunchbase раунды финансирования были — но небольшие; точные суммы не выведены в надёжные источники (data gap). Собственная позиция dossier честно фиксирует MultiOn как «маленькую компанию с риском закрытия или замедления разработки» — это официальная оценка составителя, а не наша интерпретация.

Мы ставим Lindy 5/10 и MultiOn 4/10. Разница в один балл — не за красоту графика, а за одну строчку в собственном dossier MultiOn: «маленькая компания, риск закрытия или замедления разработки». Такую формулировку производитель сам про себя обычно не пишет; когда она попала в dossier, мы принимаем её как честный сигнал и снижаем на пункт.

Сценарий 1. Автоответ и триаж на общий ящик поддержки. На [email protected] прилетает 40–60 писем в день. Половина — типовые вопросы, четверть — жалобы, требующие escalation, остальные — спам и промо. Lindy читает входящие через OAuth к Gmail, классифицирует по темам, отвечает на типовые запросы по шаблонам из Knowledge Base компании, а сложные случаи с пометкой «escalated» кладёт в отдельную папку для оператора. Это top-кейс, который сама компания выделяет как флагман. MultiOn в этой задаче не поможет — у него нет ни email-интеграции, ни классификатора.

Сценарий 2. Meeting notetaker с автозаполнением CRM. После каждого Zoom-звонка Lindy подключается к записи, транскрибирует, формирует summary и action items, и сам создаёт задачи и обновляет карточку клиента в HubSpot или Salesforce. Один workflow заменяет четыре ручных шага после звонка: расшифровка, конспект, задачи, CRM. MultiOn не подключается к Zoom и не пишет в HubSpot — вне его области.

Сценарий 3. Lead qualification для входящих заявок. На форме сайта поступает заявка — Lindy сразу отвечает уточняющими вопросами (бюджет, команда, дедлайн), квалифицирует лид по внутренним правилам компании и создаёт deal в CRM с корректным статусом. Для сейлз-команды в 3–5 человек это позволяет держать SLA на первый ответ в минутах, а не часах.

Сценарий 4. Customer support на базе Knowledge Base. Компания загружает свою внутреннюю документацию, инструкции и FAQ в Lindy Knowledge Base — агент отвечает клиентам, опираясь только на эти документы, а не на общее знание LLM. Escalation срабатывает, когда вопрос выходит за пределы базы. Для команды с 10–20 повторяющихся вопросов в день это снимает нагрузку с оператора первой линии.

Сценарий 5. Multi-agent workflow. Один Lindy принимает лид, второй пишет follow-up через две недели, третий подключается, если клиент ответил. Каждый агент — специалист на своём шаге, они передают задачи друг другу. У MultiOn такой архитектуры делегирования между сессиями нет: каждый вызов API — изолированная задача.

Зеркальная подтема. Пять задач, где MultiOn закрывает работу за 20 строк Python, а Lindy не подходит по фундаментальной причине — у него нет доступа к произвольным сайтам.

Сценарий 1. Мониторинг цен конкурентов в e-commerce. Раз в сутки нужно зайти на 15 сайтов конкурентов, найти карточки конкретных SKU, вытащить текущие цены и сложить их в свою базу. MultiOn поднимает managed-браузер, LLM-слой обходит стандартные динамические сайты и через retrieve отдаёт структурированные данные. Разработчик пишет короткий Python-скрипт, запускает по крону. У Lindy для этой задачи нет ни одного подходящего блока — доступ к чужим сайтам не поддерживается.

Сценарий 2. Автоматический вход в legacy-админку без API. Ваш SaaS-поставщик даёт данные только через веб-интерфейс — API у него нет и не будет. MultiOn заходит на страницу логина, использует stateful-сессию для сохранения куков, идёт в раздел отчётов, скачивает CSV. Для интегратора это стандартная задача, которую раньше решали через хрупкий Selenium с руками поддержки, — MultiOn делает её на уровне «5–10 строк кода вместо 300».

Сценарий 3. Заполнение форм на портале клиента внутри вашего SaaS. В продукте есть фича: пользователь загрузил данные, а вы автоматически регистрируете его заявку на портале госуслуг или партнёра. MultiOn API вызывается из вашего бэкенда, задача формулируется на естественном языке — «зайди на такой-то сайт, заполни поля X, Y, Z моими данными, дождись подтверждения, верни номер заявки». Lindy для этого не подходит по определению — нет embedded API.

Сценарий 4. QA-тестирование пользовательских путей. Каждый релиз нужно проверять, что регистрация, оплата, восстановление пароля работают. Раньше это делал Playwright с падающими на каждую вёрстку тестами. MultiOn через natural-language-задачу «зайди на сайт, зарегистрируйся с тестовыми данными, оплати картой 4242 4242, проверь письмо-подтверждение» устойчивее к косметическим изменениям вёрстки — потому что понимает страницу семантически, а не по CSS-селекторам.

Сценарий 5. Прототип встроенного browser-агента в вашем продукте. Стартап хочет добавить в свой SaaS фичу «наш ассистент сходит на 5 маркетплейсов и соберёт вам сводную таблицу товаров». MultiOn — самый короткий путь к прототипу: не нужно поднимать managed-browser-инфраструктуру, LLM-провайдер уже интегрирован. Через месяц-два прототип покажет спрос — тогда можно принимать решение о самопостроенной альтернативе.

Портрет 1. Основатель SaaS-команды на 10 человек, тонет в почте. Общий ящик hello@, входящих 80 в день, четверть — рабочие, остальное — рассылки и промо. Хочет виртуального ассистента, который отфильтрует и по простым запросам ответит сам. Наш совет: Lindy. Начните с Free — соберите шаблон email-триажа на своих 30 письмах, посмотрите долю корректных ответов. Если она устраивает — идите на Pro, средняя экономия по нашим тестам похожих команд — 4–6 часов в неделю на одного оператора.

Портрет 2. Backend-разработчик в стартапе, строит фичу мониторинга конкурентов. Задача — раз в сутки собирать данные с 20 сайтов, у 15 из которых нет API. Умеет писать Python. Наш совет: MultiOn. Free/Developer покроет тесты на неделю, после чего платный тариф позволит запускать по крону. Lindy не рассматривается — нет доступа к произвольным сайтам, нет API для встраивания в бэкенд.

Портрет 3. Sales-команда из 3 SDR с HubSpot. Каждый SDR теряет час в день на заполнение карточек после звонков и на ручной follow-up. Наш совет: Lindy. Meeting notetaker + автозаполнение HubSpot — прямой топ-кейс сервиса. Возьмите Business-тариф (от $99/мес) на команду, сравните перед покупкой credits-бюджет со своим реальным объёмом звонков (dossier предупреждает, что credits сгорают быстрее ожидаемого — считайте с запасом).

Портрет 4. QA-инженер веб-приложения. Каждый релиз — 30 регрессионных тестов на UI, Playwright ломается на каждой смене вёрстки. Наш совет: MultiOn. Natural-language-описание пользовательского пути устойчивее к косметическим правкам, чем CSS-селекторы. Начните с 3–5 самых хрупких сценариев, если стабильность окажется ощутимо выше — переводите весь регресс.

Портрет 5. Соло-консультант, живёт в Google Calendar и Notion. Клиенты пишут в почту, встречи через Google Meet, задачи в Notion, счета через Stripe. Хочет ассистента, который снимет рутину планирования и follow-up. Наш совет: Lindy. Все интеграции у него есть из коробки, тариф Pro (~$49.99/мес) для одиночного пользователя укладывается в бюджет консультанта, а не команды. MultiOn не подходит — нет ни одного нужного коннектора.