Система учёта визитов медицинских представителей: от идеи до 7,500 визитов в месяц

Ключевые цифры проекта:

• 7,580 визитов за 3 месяца в одной компании
• 1 минута 15 секунд — среднее время фиксации визита
• 411 часов в месяц экономии рабочего времени
• +12% рост продаж за квартал после внедрения
• 205,500 рублей в месяц экономии для команды из 20 человек

В дополнение к статье https://shknv.ru/320-2/

Предыстория: как всё начиналось

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

Три года назад я работал с одной фармацевтической компанией над интеграцией их систем. В офисе на стене висел огромный календарь, весь исписанный маркерами разных цветов — это была попытка визуализировать, кто из представителей где был и куда едет. Выглядело впечатляще, но совершенно неэффективно.

Коммерческий директор жаловался: «У нас 15 представителей в Петербурге, каждый делает по 10-15 визитов в неделю. Но я понятия не имею, что происходит на этих встречах. Раз в неделю мы собираемся на планёрку, они рассказывают по памяти, что было. Половина деталей уже забыта, конкретики никакой».

Тогда я решил создать специализированное решение, которое закроет эту боль. Не универсальную CRM, а именно инструмент для учёта визитов полевых сотрудников.

Постановка задачи: что на самом деле нужно пользователям

Я провёл серию интервью с медицинскими представителями, руководителями отделов и директорами. Выяснилось, что у каждой роли свои потребности, и система должна закрывать их все одновременно.

Потребности медицинских представителей

• Скорость фиксации. Не хочется тратить 5-10 минут на заполнение формы сразу после встречи. Идеально — 1 минута
• Работа без интернета. В подвале клиники или на окраине города связи может не быть
• Доступ к истории. Перед визитом нужно быстро вспомнить, что обсуждали в прошлый раз
• Простота. Никаких сложных интерфейсов — только самое важное
• Мобильность. Работать с телефона, а не только с ноутбука

Потребности руководителей отделов

• Видимость активности. Кто где был, сколько визитов сделано за день/неделю/месяц
• Качество работы. Не просто факт визита, а что именно обсуждалось, какой результат
• Быстрая реакция на проблемы. Если представитель пять раз подряд получает отказы в одной клинике — нужно помочь
• Распределение нагрузки. Понимать, кто перегружен, а у кого свободное время
• Передача клиентов. Когда сотрудник уходит или переходит на другую территорию — новичок должен быстро войти в курс дела

Потребности директоров

• Общая картина по компании. Сколько визитов в месяц делается в целом, динамика по регионам
• ROI полевой работы. Сколько стоит один визит, как это коррелирует с продажами
• Стратегические решения. В какие клиники имеет смысл вкладываться, а какие бесперспективны
• История как актив. База знаний о клиентах — это актив компании, а не личная записная книжка сотрудника

Как работает система: схема процесса

Процесс работы представителя (пользовательский сценарий)

Итого: представитель тратит ~1 минуту вместо 1 часа вечером на заполнение Excel

Технический процесс синхронизации (для понимания надёжности)

1. Создание визита: пользователь заполняет форму в приложении (React PWA)
2. Локальное сохранение: данные сохраняются в IndexedDB браузера (работает без интернета)
3. Очередь синхронизации: визит добавляется в очередь на отправку
4. Попытка отправки: при появлении сети автоматически отправляется на сервер (FastAPI)
5. Повторные попытки: если ошибка — повторная попытка через 5 сек, 30 сек, 2 мин, 5 мин
6. Валидация: сервер проверяет данные, связывает с пользователем и компанией
7. Сохранение в БД: запись в PostgreSQL с timestamp
8. Отправка в Bitrix24: через REST API создаётся элемент в смарт-процессе
9. Связывание записей: ID из Bitrix24 сохраняется в нашей БД (для двусторонней синхронизации)
10. Подтверждение клиенту: приложение получает статус «синхронизировано»

Надёжность: даже если представитель целый день был без связи (15 визитов), вечером при подключении к Wi-Fi всё синхронизируется автоматически за 2-3 минуты.

Бизнес-кейсы: реальные истории внедрения

Кейс 1: Фармацевтическая компания в Санкт-Петербурге

О компании:

• Поставка медицинского оборудования и препаратов для клиник
• Команда: 18 медицинских представителей + 3 руководителя отделов + 1 региональный директор
• География: Санкт-Петербург и Ленинградская область (350+ клиник в базе)
• До внедрения: Excel-таблицы, которые представители заполняли вечером по памяти

Проблемы до внедрения:

• Представители тратили по 1 часу каждый вечер на заполнение отчётов
• Много деталей терялось — люди забывали, что обсуждали утром
• Руководители видели информацию только раз в неделю на планёрке
• При уходе сотрудника новичок начинал с нуля — не знал историю клиентов
• Невозможно было понять, какие клиники перспективные, а какие тратят время впустую

Процесс внедрения:

1. Неделя 1: Анализ потребностей, встреча с руководством (2 дня)
2. Неделя 2: Настройка интеграции с Bitrix24, загрузка базы клиник (3 дня)
3. Неделя 3: Пилот с 3 продвинутыми пользователями (5 дней)
4. Неделя 4: Обучение всех 18 представителей (1 день), старт работы (3 дня адаптации)

Результаты через 3 месяца:

Конкретные цифры за первые 3 месяца:

• Зафиксировано 7,580 визитов (в среднем 140 визитов в неделю на команду из 18 человек)
• Среднее время создания одного визита: 1 минута 15 секунд
• Общая экономия времени: с 18 часов в день до 3 часов (18 человек × 1 час → 18 человек × 10 минут)
• Это освободило 15 часов в день или ~330 часов в месяц рабочего времени
• В деньгах (при ставке 500₽/час): экономия 165,000₽ в месяц только на представителях

Неожиданный эффект — аналитика:

Через месяц работы руководитель отдела обратил внимание на статистику и обнаружил интересное: три крупные клиники показывали стабильно низкий результат визитов. Из 15 последних визитов в каждую — 12-13 отказов. Раньше эта информация терялась в общем потоке.

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

Решение: перераспределили усилия на 12 других клиник с более высокой конверсией. Результат — рост продаж на 12% за следующий месяц при том же количестве визитов.

«Раньше я каждый вечер тратила по часу на отчёты. Сейчас просто фиксирую визиты на месте за минуту, всё автоматически синхронизируется с Битрикс24. Сэкономленное время трачу на дополнительные визиты. За месяц сделала на 15 визитов больше, чем раньше.»

«Главная ценность — это история. Когда мы берём нового сотрудника на территорию, он за вечер изучает всю базу знаний по клиентам: кто там работает, какие были встречи, что обсуждали, какие препараты интересны. Раньше нужно было месяц вникать, ездить вместе со старшим коллегой. Сейчас новичок после недели уже работает самостоятельно.»

Кейс 2: Компания с распределёнными командами (Москва + Краснодар)

О компании:

• Дистрибьютор фармацевтической продукции
• Команда: 25 представителей в Москве + 8 представителей в Краснодаре
• Особенность: разные часовые пояса, разные руководители, общий директор
• До внедрения: две разные системы учёта (Москва вела в Google Sheets, Краснодар в Excel)

Проблемы до внедрения:

• Директор не мог увидеть общую картину по компании
• Московская и краснодарская команды использовали разные форматы отчётности
• Невозможно было сравнивать эффективность регионов
• При обмене опытом между командами не было единой базы знаний
• Путаница с временными зонами: когда какой визит состоялся?

Решение:

• Единая система для всех регионов с разграничением прав доступа
• Московская команда видит только своих клиентов, краснодарская — только своих
• Руководители видят свои команды, директор — всё
• Автоматический учёт часовых поясов (время визита записывается в UTC, показывается в локальном времени пользователя)
• Единый формат данных для аналитики и сравнения

Результаты через 8 месяцев:

• Обрабатывает 600-700 визитов в неделю стабильно
• Никаких жалоб на права доступа или путаницу с данными
• Директор получает еженедельный автоматический отчёт: сколько визитов в каждом регионе, динамика, проблемные зоны
• Выявили лучшие практики краснодарской команды (у них была выше конверсия визитов) и распространили на Москву
• Общая эффективность выросла на 8% за полгода

«Наконец-то я вижу реальную картину работы обоих офисов, а не только то, что мне рассказывают на еженедельных созвонах. Могу быстро заметить, если в каком-то регионе проседает активность, и помочь. Например, в мае увидел, что в Краснодаре резко упало количество визитов — оказалось, что двое заболели. Оперативно перераспределили нагрузку.»

Кейс 3: Стартап в медицинской технике (малая команда)

О компании:

• Молодая компания, продажа медицинского оборудования для диагностики
• Команда: 5 представителей + 1 руководитель (он же основатель)
• География: Москва и Подмосковье
• До внедрения: вообще никакого учёта, всё в головах и телефонных заметках

Проблемы до внедрения:

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

Особенность внедрения:

У стартапа не было Bitrix24 и вообще никакой CRM. Внедрили только систему учёта визитов без интеграции. Вся информация хранится в собственной базе данных системы.

Результаты через 4 месяца:

• Зафиксировано 1,240 визитов (около 60 в неделю на команду из 5 человек)
• Основатель впервые увидел реальную картину работы: кто продуктивен, кто тратит время неэффективно
• Выявили, что один представитель делал много визитов, но конверсия была 5% (против 25% в среднем по команде)
• Провели обучение, поделились скриптами успешных коллег — конверсия выросла до 18%
• База клиентов стала структурированным активом компании, а не набором визиток в кармане сотрудников
• При привлечении инвестора смогли показать структурированные данные о работе с клиентами

«Как основатель я делал всё на интуиции первые два года. Когда внедрили систему, впервые увидел цифры. Оказалось, что мои предположения о работе команды были верны только наполовину. Теперь принимаю решения на основе данных, а не догадок.»

Кейс 4: Крупная федеральная компания (масштаб)

О компании:

• Федеральный дистрибьютор медицинских препаратов
• Команда: 87 представителей в 12 регионах России
• Структура: представители → руководители отделов (12 чел.) → региональные директора (4 чел.) → коммерческий директор
• До внедрения: хаос из Excel, 1С, Bitrix24, блокнотов и WhatsApp-отчётов

Проблемы до внедрения:

• Каждый регион вёл учёт по-своему
• Коммерческий директор получал сводку раз в месяц, уже неактуальную
• Невозможно было сравнить эффективность регионов (разные метрики)
• Текучка кадров 30% в год — знания о клиентах терялись
• Дублирование визитов: представители из разных отделов ездили к одному клиенту, не зная друг о друге

Особенность внедрения:

Поэтапное внедрение: сначала пилот в одном регионе (Новосибирск, 8 человек), через месяц — ещё в трёх регионах, через два месяца — во всех остальных.

Результаты через 6 месяцев:

• Обрабатывается ~2,500 визитов в неделю по всей компании
• Единая система учёта для всех 87 представителей
• Коммерческий директор видит дашборд в реальном времени: активность по регионам, топ-клиенты, проблемные зоны
• Выявили и устранили дублирование визитов — экономия 12% времени представителей
• Текучка кадров снизилась до 18% (потому что новички быстрее входят в работу благодаря структурированной базе знаний)
• Экономия времени: ~1,450 часов в месяц на всю компанию
• В деньгах: ~725,000₽ в месяц экономии рабочего времени

«Впервые за 5 лет работы компании у меня есть единая картина того, что происходит на местах. Раньше региональные директора присылали отчёты в PowerPoint раз в месяц — красивые слайды, но нулевая оперативность. Сейчас я открываю дашборд и за 2 минуты вижу, где всё хорошо, а где нужно вмешаться.»

Подробный расчёт экономической эффективности

Расчёт для команды из 20 представителей (типичный размер отдела)

Исходные данные:

• Количество представителей: 20 человек
• Руководителей: 2 человека
• Визитов в день на одного представителя: 3-4 (в среднем 3.5)
• Рабочих дней в месяц: 22
• Стоимость часа работы представителя: 500₽
• Стоимость часа работы руководителя: 800₽

Экономия времени представителей

Расчёт экономии для представителей:

• Экономия в день на одного: 62 минуты ≈ 1 час
• Экономия в день на 20 человек: 20 часов
• Экономия в месяц: 20 часов × 22 дня = 440 часов
• В деньгах: 440 часов × 500₽ = 220,000₽/месяц

Экономия времени руководителей

Расчёт экономии для руководителей:

• Экономия в день на одного: 1.25 часа
• Экономия в неделю на одного: 5 часов (3.5 + 1.5)
• Экономия в месяц на 2 руководителей: (1.25 × 22 + 5 × 4) × 2 = 95 часов
• В деньгах: 95 часов × 800₽ = 76,000₽/месяц

Итоговая экономия

Дополнительные бизнес-эффекты (сложно оценить точно, но они есть):

• +15-20% визитов в месяц: освободившееся время позволяет сделать больше встреч
• +5-10% конверсия: лучшая подготовка к визитам (есть история) даёт больше успешных встреч
• Снижение текучки: новички быстрее входят в работу → меньше увольнений в первые 3 месяца
• Лучшие решения: аналитика на основе данных вместо интуиции
• Конкурентное преимущество: более профессиональный подход к клиентам

Окупаемость системы (пересчёт)

Типичные расходы на внедрение:

• Настройка и интеграция: 250,000-350,000₽ (среднее: 300,000₽)
• Обучение персонала: 20,000-40,000₽ (среднее: 30,000₽)
• Месячная подписка: 15,000-30,000₽ (для расчёта возьмём: 30,000₽)

Окупаемость для команды из 20 человек:

Первоначальные затраты:

• 300,000₽ (интеграция) + 30,000₽ (обучение) = 330,000₽

Ежемесячная экономия:

• 296,000₽ (как рассчитали ранее: 220,000₽ представители + 76,000₽ руководители)

Окупаемость:

• 330,000₽ ÷ 296,000₽ = 1.11 месяца
• Это примерно 5 недель (или чуть больше месяца)

Чистая выгода за первый год:

• Экономия за год: 296,000₽ × 12 = 3,552,000₽
• Минус первоначальные затраты: -330,000₽
• Минус годовая подписка: 30,000₽ × 12 = -360,000₽
• ИТОГО: 2,862,000₽ чистой прибыли

Технические особенности: почему это работает надёжно

PWA (Progressive Web Application) вместо нативного приложения

Почему выбрали PWA:

• Кроссплатформенность: один код для iOS, Android, Web — не нужно разрабатывать 3 версии
• Мгновенное обновление: новая версия разворачивается на сервере и все пользователи получают её автоматически, не нужно ждать модерацию App Store/Google Play
• Работа без установки: открыл ссылку в браузере — уже работаешь, можешь добавить на главный экран
• Оффлайн-режим: Service Workers кэшируют приложение и данные, всё работает без интернета
• Меньше затрат: не нужно платить за аккаунты разработчика Apple ($99/год) и Google ($25 разово)

Как работает оффлайн:

1. При первом открытии приложение загружается в браузер и кэшируется
2. Service Worker перехватывает все запросы к серверу
3. Если интернета нет — данные сохраняются в IndexedDB (локальная база в браузере)
4. Когда интернет появляется — Service Worker автоматически синхронизирует данные с сервером
5. Пользователь не замечает разницы — просто работает

Двусторонняя синхронизация с Bitrix24

Как работает интеграция:

1. Маппинг полей: в админке настраивается соответствие между полями системы и Bitrix24 (например, «Название клиники» → «TITLE», «ИНН» → «UF_CRM_1234567890»)
2. Создание визита в системе: представитель заполняет форму
3. Сохранение в нашей БД: данные попадают в PostgreSQL
4. Отправка в Bitrix24: через REST API создаётся элемент в смарт-процессе «Визиты»
5. Получение ID: Bitrix24 возвращает ID созданной записи
6. Связывание: ID из Bitrix24 сохраняется в нашей БД в поле bitrix_id
7. Обратная синхронизация: если в Bitrix24 меняется статус визита или добавляется комментарий — webhook уведомляет нашу систему
8. Обновление в системе: изменения из Bitrix24 применяются к записи в нашей БД

Преимущества двусторонней синхронизации:

• Представители работают в удобном интерфейсе, оптимизированном для мобильных
• Менеджеры и руководители видят всё в привычном Bitrix24
• Можно добавлять комментарии и изменять статусы с обеих сторон
• История всегда синхронна

Динамические поля для гибкости

Каждая компания имеет свою специфику: кто-то фиксирует количество розданных образцов, кто-то — количество врачей на встрече, кто-то — температуру в помещении (для медицинского оборудования). Чтобы не переделывать систему под каждого клиента, используем динамические поля.

Как это работает:

• В базе данных есть поле dynamic_fields типа JSONB
• Туда можно записать любые дополнительные данные: {"samples_given": 5, "doctors_present": 3}
• В админке настраивается, какие поля показывать в форме визита
• Форма генерируется динамически на основе настроек
• PostgreSQL умеет индексировать JSONB и быстро искать по этим полям

Пример настройки для фармацевтической компании:

Проблемы, с которыми столкнулся при разработке и как решил

Проблема 1: Производительность при больших объёмах данных

Симптомы:

Когда в первой компании накопилось 7,000+ визитов, загрузка страницы со списком визитов стала занимать 5-7 секунд. Пользователи жаловались.

Причина:

API тянул все визиты сразу, JSON-ответ весил несколько мегабайт. Браузер тормозил при рендере такого большого списка.

Решение:

• Пагинация: показываем по 50 записей на страницу, остальные подгружаем по требованию
• Фильтр по датам: по умолчанию показываем только визиты за последний месяц (обычно этого достаточно)
• Индексы в БД: добавил составные индексы (user_id, date) и (company_id, date) для быстрых выборок
• Кэширование на клиенте: React Query кэширует загруженные данные, повторные запросы идут из кэша
• Виртуализация списка: рендерим только видимые элементы, остальные не создаём в DOM

Результат:

Время загрузки вернулось к 1-2 секундам даже при 10,000+ визитов в базе.

Проблема 2: Сложность интерфейса (первая версия была провалом)

История провала:

Первая версия была перегружена функциями:

• 15 полей для заполнения (большинство опциональных, но всё равно отпугивало)
• Встроенный чат для обсуждения визитов с коллегами
• Карта с маршрутами
• Прогноз погоды
• Калькулятор для расчёта объёма заказа
• Меню с 3 уровнями вложенности

Пилотная группа из 3 человек протестировала неделю. Отзывы:

• «Слишком сложно, проще в блокнот записать»
• «Запутался в меню, не нашёл нужную функцию»
• «Зачем мне погода? Я и так на улице»
• «На создание визита уходит 3-4 минуты, это долго»

Решение: радикальное упрощение

Переделал с нуля:

• 4 обязательных поля: Клиника, Врач (если есть), Результат (успешно/отказ/перенос), Комментарий
• Всё остальное опционально и скрыто за кнопкой «Дополнительно»
• Плоская навигация: главное меню с 5 пунктами, без вложенности
• Убрал: чат (есть Telegram), карты (есть Google Maps), погоду, калькулятор
• Фокус на скорости: от открытия формы до сохранения визита — 30-40 секунд

Результат:

Вторая версия заработала. Активность выросла в 3 раза по сравнению с пилотом первой версии. Среднее время создания визита — 1 минута 15 секунд.

«Первая версия была как комбайн — 100 функций, 99 из которых не нужны. Вторая версия — это просто инструмент, который делает одно дело, но хорошо.»

Проблема 3: Разные версии Bitrix24 у клиентов

Симптомы:

У каждой компании Bitrix24 настроен по-своему: разные названия полей, разные структуры, разные версии API.

Решение: система маппинга полей

Создал таблицу field_mappings, где хранится соответствие между полями системы и Bitrix24 для каждой компании:

При интеграции с новой компанией:

1. Запрашиваю через API список всех полей в их Bitrix24
2. Показываю их в админке
3. Администратор вручную сопоставляет наши поля с их полями
4. Сохраняю маппинг в БД
5. Дальше всё работает автоматически на основе этого маппинга

Результат:

Интеграция с новой компанией занимает 1-2 часа вместо нескольких дней переписывания кода.

Процесс внедрения: как это происходит на практике

Типичный план внедрения (3-4 недели)

Что нужно от клиента для внедрения

• Доступ к Bitrix24: webhook URL или права администратора для настройки OAuth
• Список пользователей: ФИО, email, роли (представитель/руководитель/директор)
• База клиентов: желательно выгрузить из Bitrix24, чтобы не вводить вручную
• Время на обучение: 1 час для группового обучения персонала
• 2-3 продвинутых пользователя для пилота: они первыми протестируют и дадут обратную связь
• Техническая часть: сервер для развёртывания (можно предоставить наш, можно на их инфраструктуре)

Что дальше: планы развития системы

1. Календарное представление визитов

Визуализация встреч на календарной сетке (день/неделя/месяц) с возможностью drag-and-drop для переноса визитов между днями. Сейчас визиты показываются списком — удобно для истории, но не очень для планирования.

2. Умная аналитика на основе истории

• Оптимальная частота визитов: система анализирует, как часто нужно ездить к разным категориям клиентов для максимальной конверсии
• Предсказание успешности: на основе истории предсказываем, в какой день недели и время лучше ехать к конкретной клинике
• Рекомендации по приоритетам: «Клиника Х давно не посещалась, а раньше была перспективной» или «Клиника Y показывает рост интереса — стоит уделить больше внимания»
• Сезонность: анализ, когда клиенты более активны (например, в медицине есть сезонность по заболеваниям)

3. Прикрепление файлов к визитам

Возможность прикрепить к визиту документы: договор, презентацию, фотографию, скан. Ограничение: до 5 файлов по 10 МБ на визит. Форматы: PDF, JPG, PNG, DOCX.

Сценарий: представитель после встречи фотографирует подписанный договор и прикрепляет к визиту — руководитель сразу видит, что сделка закрыта.

4. Интеграция с другими CRM

Сейчас поддерживается только Bitrix24. Планируется добавить:

• AmoCRM
• 1С:CRM

Модульная архитектура позволяет добавлять коннекторы без переписывания основного кода.

5. Геолокация и карта визитов

• Автоматическое определение геопозиции при создании визита
• Визуализация на карте: где был представитель сегодня, какие клиники рядом
• Оптимальный маршрут на день с учётом пробок (интеграция с Яндекс.Картами или Google Maps)
• Контроль: действительно ли представитель был в клинике (по геопозиции) или создал визит из офиса

6. Мобильные уведомления

Push-уведомления для представителей:

• «Напоминание: сегодня встреча в клинике X в 14:00»
• «Вы давно не были в клинике Y — запланируйте визит»
• «Руководитель оставил комментарий к вашему визиту»

7. Интеграция с бухгалтерией

Автоматический расчёт расходов на визиты:

• Километраж (на основе геопозиции)
• Компенсация ГСМ
• Суточные
• Автоматическая выгрузка в 1С для бухгалтерии

Заключение: ключевые уроки разработки

Создание системы учёта визитов заняло около 6 месяцев активной разработки + ещё 6 месяцев доработок по обратной связи от реальных пользователей. Сейчас система стабильно работает в нескольких компаниях, обрабатывает тысячи визитов в месяц, и я получаю положительные отзывы.

5 главных уроков, которые я вынес

1. Простота важнее функциональности. Лучше 5 функций, которыми пользуются, чем 50, которые только запутывают. Первая версия провалилась именно из-за перегруженности. Вторая, упрощённая, выстрелила.
2. Оффлайн-режим — не фича, а обязательное требование. Для полевых сотрудников это критично. Без оффлайна система просто не будет использоваться в половине ситуаций.
3. Интеграция важнее изоляции. Не нужно создавать ещё одну изолированную систему. Система должна вписываться в существующие процессы и интегрироваться с тем, что уже используется (Bitrix24, 1С, и т.д.).
4. Слушайте пользователей, а не свои идеи. Половину лучших функций предложили сами пользователи после начала работы. Например, идею динамических полей подсказал клиент, который сказал: «А можно ещё фиксировать температуру в помещении? У нас оборудование чувствительное». Я сделал универсальное решение — и оно пригодилось всем.
5. Итерируйте быстро. MVP + обратная связь + доработки лучше, чем год разработки в вакууме. Я запустил первый пилот через 2 месяца разработки — и получил массу ценных инсайтов, которые никогда бы не пришли в голову за столом.