Александр

Да это классика, мы сами недооценили этот момент. По приоритету что сработало:

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

Второе - поменяли kpi. Раньше было "обработал заявку", стало "закрыл сделку". У тех кто пользуется ботом сделок в среднем больше потому что времени на общение с клиентом больше. Это самый честный аргумент, цифры в ведомости спорить не умеют.

Третье - бот живёт прямо в их рабочем окне, не отдельная вкладка. Лишний клик это всегда барьер.

Четвёртое и неприятное - один из четырёх менеджеров не принял категорически, активно ломал процесс. Через месяц расстались. Больно, но 3 продуктивных с ботом сильно лучше чем 4 уставших без него.

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

Хороший вопрос — это вообще главная боль таких систем. Решали в 3 слоя:

1. Health-check в Postgres. Каждый парсер пишет в Postgres счётчик найденных позиций за последние 24 часа. Если упало на 50%+ от среднего - уведомление в Telegram. Это ловит примерно 80% поломок.

2. AI-fallback на критичных полях (цена, остаток): если основной CSS-селектор вернул нереалистичный результат (цена 10млн, остаток отрицательный) - кидаем HTML страницы в GPT 4o mini с промтом "найди цену в этом блоке". Дороже, но ловит тихие поломки, когда селектор формально работает, а возвращает мусор.

3. Якорные SKU. У каждого источника есть 5-10 артикулов, про которые мы точно знаем - должны быть в наличии всегда (популярные позиции). Раз в час проверяем. Нет ни одного - парсер сломался.

Playwright в Docker помогает изолировать: при поломке апдейтим один контейнер, а не тянем регрессию по всей системе.

Из 9 источников реально проблемными оказались 2 - у них фронт периодически меняется. По ним в итоге договорились с поставщиком про XML-фид, парсинг с них убрали совсем. Иногда договориться сильно дешевле, чем допилить парсер.

Не уместилось в статью, но самая большая проблема была не в коде.
Первые две недели менеджеры просто игнорировали бота — продолжали лазить по 9 сайтам руками. Не доверяли. Сначала думали, что нужен ещё один бот-«контролёр». В итоге сработало проще: руководитель отдела стал каждый вечер смотреть, у кого диалоги с ботом есть, у кого нет. Тех, кто не использовал, спрашивал «почему?». Через три дня все начали брать бота в работу.
Самое нелогичное: технически мы могли сделать всё то же ещё полгода назад. Но внедрение нового инструмента в зрелой команде — это не разработка, это change management. У кого был опыт похожих «социальных» граблей при автоматизации?