Как я автоматизировал Wollmer

Зачем этот канал

На ревью нормальная практика — «давай за три минутки». И это правильно, у команды нет времени слушать, как я неделю искал причину.

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

Вот про это и буду писать. Здесь можно подробно.

Что тут будет

• Разборы проектов — от боли до работающего инструмента
• Было / стало — коротко и в цифрах
• Грабли — что сломалось и чему научило
• Из-под капота — как устроено то, чем вы пользуетесь каждый день
• Спросите ИТ — ответы на частые вопросы

Половина того, что я делаю, меняет вашу работу: форму, задачу, кнопку в CRM. Здесь можно заранее понять, что меняется, и сказать «стоп, так неудобно» — до того, как оно уедет в бой.

Сегодня выкладываю все статьи за полтора года. Комментарии открыты)

Полтора года: от «выдайте мышку» до архитектуры

Выгрузил все свои задачи и посмотрел подряд. Картина получилась наглядная.

Цифры

С марта 2025 по август 2026 закрыл 1472 задачи. Пик — 133 за июль 2025.

Но интереснее не количество, а из чего оно состоит.

Доля задач «починить железо и рабочее место»:

• первая половина 2025 — 22%
• сейчас — 6%

Доля задач «настроить и перестроить процесс»:

• первая половина 2025 — 7%
• сейчас — 23%

За полтора года ремонт ноутбуков и проектирование процессов поменялись местами почти зеркально.

Цифра, которая меня удивила

В начале 2025 на каждую задачу, поставленную кому-то другому, приходилось 12 закрытых своими руками. В 2026 — 6.

Соотношение изменилось ровно вдвое. Это и есть переход от «я делаю» к «я придумываю, как это должно работать».

Три вывода

1. Рост — это не «сложнее технически», а «дальше горизонт».
2. Скучные задачи вроде реестра ключей не выглядят достижением ровно до дня, когда спасают.
3. Главное умение — не чинить, а спрашивать «почему это вообще произошло».

Если кажется, что вы полтора года делаете одно и то же — выгрузите свои задачи и почитайте подряд. Я честно удивился)

Как устроен поток заявок в ИТ

Многое, что выглядит бюрократией, решает конкретную проблему. Объясню.

Правила

• Работаем с 10:00 до 19:00
• Первая обратная связь — в течение трёх рабочих часов
• Задача не принята три рабочих дня после выполнения — считается завершённой
• Нет ответа от сотрудника больше пяти дней — обращение закрывается

Последние два пункта вызывали вопросы. Логика простая: без них доска забивается сделанными, но не подтверждёнными задачами. Через месяц там сотня «висяков», и настоящие проблемы теряются.

Три поля, которые мы просим заполнить

Разница между «не работает почта» и «не отправляются письма на внешние адреса с 14:00, ошибка такая-то» — это два часа поисков против десяти минут.

Отдельно про ожидаемый результат. Самое частое, что тормозит задачу — я не знаю, что для вас значит «готово».

Про приоритеты

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

И ещё

Стадия «Ждёт уточнения» — это не отфутболивание. Это значит, что без вашего ответа я сделаю не то.

Если задача зависла — пишите в неё, а не в личку. В личке теряется, в задаче видна всем.

Возврат денег клиенту: было 26 шагов, стало 12

Самый ручной и ошибкоёмкий процесс в компании. Разбираю.

Как было

Клиент от руки заполнял заявление и печатал. Менеджер вручную переносил данные в Usedesk, оформлял забор в CRM, ставил задачу складу, заводил бизнес-процесс. Бухгалтерия перепечатывала реквизиты с фотографии.

26 шагов, 6 участников, 5 систем, которые между собой не разговаривают.

Главная беда — реквизиты. Человек переписывает двадцать цифр с фото. Ошибся в одной — банк вернул платёж, клиент ждёт ещё неделю.

Что было непросто

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

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

Что сделали

1. Форма refund.wollmer.ru, ссылка генерируется прямо в тикете Usedesk
2. Реквизиты проверяются при вводе — неправильный счёт не отправится
3. Заявление формируется само, PDF с подписью клиента прямо в форме
4. Заказ-забор в CRM создаётся автоматически
5. Поля рекламации и задача складу — тоже сами
6. По ответу ОКК стартует бизнес-процесс оплаты

Было / стало

• Шагов: 26 → 12
• Заявление: от руки → формируется само
• Реквизиты: перепечатываются с фото → проверяются при вводе

Дальше разберу отдельно проверки, юридическую часть и грабли с Интегралом.

Форма, которая не даёт ошибиться

Продолжаю про возвраты. Почему клиент физически не может отправить неправильные реквизиты.

Постановка

Прошлые попытки сделать онлайн-форму сворачивали из-за одного аргумента: клиент напишет чушь, а мы получим ошибку в платеже. Аргумент справедливый.

Значит, задача не «сделать форму», а «сделать так, чтобы неправильные данные нельзя было ввести». Это разные задачи.

Что проверяется

Расчётный счёт. У счёта есть контрольный ключ — он считается из самого счёта и БИК по алгоритму Центробанка. Ошибся в одной цифре — ключ не сойдётся, форма не пропустит.

Заодно это ловит частую ошибку: клиенты присылают не расчётный счёт, а корреспондентский счёт банка. Внешне похоже, платёж уходит в никуда.

Номер карты. Алгоритм Луна — тот же, что у банков. Опечатка не проходит.

ИНН банка — формат и контрольная сумма.

Сумма прописью формируется из числа сама. Раньше писали руками, и расхождение было отдельным поводом вернуть заявление.

Главное

Ошибка перестала быть возможной не потому, что клиент стал внимательнее, а потому что форма её не принимает.

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

Разница между «просим внимательно проверить» и «неправильное не сохраняется» — это разница между инструкцией и решением.

Заявление, которое пишет себя само

Самая скучная на вид часть возвратов, в которой было больше всего работы — юридическая.

Почему нельзя было просто убрать заявление

У него две функции, обе обязательные.

Первая — это волеизъявление клиента: человек явно заявляет, что хочет вернуть товар и деньги.

Вторая — это документ для бухгалтерии. Без него платёж не проводится: деньги уходят со счёта компании, должно быть основание.

Убрать нельзя. Можно сделать так, чтобы его никто не писал руками.

Что спросил у юриста

Чем заменить подпись от руки?

Ответ: волеизъявление подтверждается простой электронной подписью — подписью прямо в форме или кодом из СМС. Оба варианта законны.

Выбрали подпись в форме: клиент расписывается пальцем или мышкой, подпись попадает в документ. СМС оставили запасным вариантом — он дороже и добавляет шаг.

Что спросил у бухгалтерии

Без чего заявление недействительно?

Оказалось — формат может быть любым, важно чтобы документ был и данные совпадали с платёжкой. Отсюда решение: PDF формируется автоматически и подгружается в заказ и в бизнес-процесс.

Побочный эффект

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

Вывод

Самая полезная часть проекта была не про код. Она была про то, чтобы сходить и спросить: что здесь обязательно по закону, а что просто привычка?

Обязательного оказалось сильно меньше, чем принято думать.

Забор Интегралом: когда у поставщика нет того, на что ты рассчитывал

Короткая история про то, как красивая схема ломается о реальность.

Как задумывалось

В цепочке возврата товар едет от клиента к нам, и складу нужно поставить задачу на проверку.

Логика простая: курьерская служба приняла посылку → появился номер накладной → значит забор состоялся → ставим задачу.

Со СДЭКом работает идеально.

Обо что споткнулись

Дошли до Интеграла — и выяснилось, что номера накладной мы у него не видим вообще. Его просто нет в наших данных.

Триггер, на котором держалась вся ветка, для второго перевозчика не существует.

Что рассматривали

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

Ставить задачу вручную для Интеграла — отпало по смыслу: мы как раз убирали ручные шаги.

Зацепиться за другое событие — то, что и выбрали. Правильный триггер подсказала Софья: задача может создаваться после перевода заказа в статус «Оформить забор».

Что сделали

Развели логику по перевозчикам:

• Интеграл — статус «Оформить забор» плюс признак автоформы
• СДЭК — как было, по номеру отправления

После правок Мадина и Алёна перетестировали и подтвердили, что нареканий нет.

Вывод

Проектируя интеграцию, легко решить, что «номер накладной есть всегда» — потому что у одного перевозчика он есть. Проверять надо каждого.

И второе: правильный триггер нашёл не я, а человек, который каждый день работает с заборами. Мой вклад был в том, чтобы прийти с конкретным вопросом, а не с «помогите придумать».

Клиент звонил тридцать минут в пустоту

Одна жалоба, которая вскрыла целый пласт проблем.

Что случилось

Клиент звонил в продажи и не смог дозвониться — вся группа ушла на обед. Он честно нажимал «1» в голосовом меню и звонил тридцать минут. В никуда.

В CRM этих звонков не было. По статистике — «пропущенный на этапе голосового меню».

Почему это хуже, чем кажется

Мы бы не узнали, если бы клиент не пожаловался. Звонок, который не дошёл, не оставляет следа — ни в отчёте, ни в карточке. Мы просто не знаем, сколько людей так и не дозвонились.

Ожидание было, что при пустой группе звонки упадут на рекламации. По факту — нет.

Чего мне не хватало

Всё упиралось в вопрос, на который я не мог ответить сам: через сколько секунд переключать на другой отдел?

Быстро — продажи теряют свои звонки. Медленно — клиент бросит трубку.

Спросил у руководителя отдела заботы. Ответ конкретный: через 30 секунд.

Это тот случай, когда ИТ не должно решать само. Цифра выглядит технической, а решение бизнесовое.

Как запускали

Новый профиль телефонии я не включил молча. Написал в задачу: всё готово, дайте отмашку и помониторьте. Договорились на следующий день с 10:00 — в рабочее время и под наблюдением, а не вечером пятницы.

Через день пришло подтверждение: «продажи ходили на обед, всё на рекламации падало». Проверили ровно тот сценарий, из-за которого всё началось.

Вывод

Самые дорогие поломки — те, которых не видно в отчётах.

Если видите что-то странное — напишите, даже если кажется, что это ерунда. Именно из «ерунды» такое и вылезает.

Звонок, который прилипал к одному менеджеру

Задача выглядела технической, а оказалась про справедливость.

Жалоба

Во время разговора приходит второй звонок. Менеджер его отклоняет, чтобы он ушёл свободному коллеге. А он через три-пять секунд снова падает на неё. И так по кругу.

При этом в статистике он записывается ей как пропущенный.

Человек уже работает с клиентом, делает всё правильно — и получает минус в отчётность.

Что выяснилось

В обсуждении всплыли две разные проблемы, которые казались одной.

Первая: если сотрудник в отделе один и он в разговоре, отклонённый звонок возвращается к нему же. Про это в заботе знали и считали «так работает».

Вторая: если на линии двое и один занят, звонок при отклонении всё равно не улетает свободному. Про это услышали впервые — и это уже точно поломка.

Разделить эти два случая было половиной решения. Пока они смешаны, чинишь не то.

Вопрос, который я задал до того, как чинить

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

Но я не стал включать сразу, а написал в задачу: не повлияет ли это на метрику?

Логика такая: звонок может автоматически получить статус «пропущен» и уйти другому — а в отчёте у первого он всё равно останется пропущенным. То есть починим маршрутизацию и одновременно испортим людям статистику.

Разобрались вместе с менеджерами, проверили на реальных звонках и включили осознанно.

Почему пишу

Цифры, по которым оценивают людей — это не техническая деталь. Если решение их меняет, об этом надо говорить до внедрения, а не после.

Если видите в своей статистике что-то непонятное — спрашивайте. Иногда это настройка, которую кто-то включил из лучших побуждений.

Одна линия, два направления

Задача из тех, где половина работы — не техника, а согласование.

Что просили

Разделить телефонную линию на две части к конкретной дате. Номер оставить один — он везде указан: на сайте, в документах, в рекламе.

«Нажмите 1 — отдел продаж, нажмите 2 — если проблема с техникой».

Зачем

До этого все звонки шли в одну кучу. Клиент, который хочет купить, и клиент, у которого сломался пылесос, попадали к одному человеку. Каждый второй звонок начинался с «сейчас переключу».

Что сделал первым делом

Не полез настраивать. Написал запрос оператору и уточнил, что вообще возможно на нашем тарифе.

Возможность есть. Но с условием, которое поменяло планирование: для голосового меню нужен записанный аудиофайл. Не галочку включить, а записать, согласовать, утвердить.

Написал об этом сразу: давайте пропишем текст. Потому что как компания представляется клиенту в первые пять секунд — решает не системный администратор.

Где встало

Текст ушёл на согласование, и дальше я несколько раз писал в задачу: скажите, когда ожидать, чтобы начать готовить настройки заранее.

Не ради галочки. Просто если аудио придёт в последний день, к дате мы не успеем физически.

Вывод

Когда у задачи есть жёсткая дата, самое важное — заранее найти в ней шаг, который зависит не от тебя.

Технически настройка меню — час работы. Но между «можно» и «работает» стоял текст, который должен написать другой отдел.

Если ставите задачу со сроком — сразу подумайте, нужно ли от вас или смежников что-то, без чего я не начну. Это экономит недели.

Почему падали созвоны

Классика: проблема, которую все считали неизбежной.

Симптом

Созвоны в Битриксе не устанавливали соединение. Трансляции в Google Meet отваливались на середине. У двух коллег звонки не запускались вообще.

Объяснение в офисе было одно: «интернет плохой». Самая удобная гипотеза — с ней ничего не надо делать.

Почему я в неё не поверил

Если бы дело было в канале, страдало бы всё одинаково: и почта, и CRM, и загрузка файлов. А страдали именно звонки и видео.

Это трафик, чувствительный к задержкам, а не к скорости. Скорость — сколько данных проходит. Задержка — насколько ровно они идут. Для видеозвонка важнее второе.

Что сделали

Взяли главный роутер:

1. Включили аппаратное ускорение — трафик обрабатывается железом, процессор перестал быть узким местом
2. Включили автоматическую приоритизацию трафика — роутер понял, что звонок важнее фоновой загрузки большого файла
3. Обновили прошивку и несколько дней наблюдали

Настраивал руками Даниил Агеев.

Результат

Созвоны у коллег, которые не могли подключиться, заработали. Проблема закрылась.

При этом канал остался тем же. Мы не покупали больше скорости — перестали тратить её впустую.

Аналогия

Это как одна полоса для скорой и для грузовика. Расширять дорогу дорого. Пропустить скорую вперёд — бесплатно и решает проблему.

Вывод

«У нас плохой интернет» — это не диагноз, а описание ощущений. Всегда стоит спросить: плохо всему или плохо чему-то конкретному? Если конкретному — дело не в канале.

Как мы меняли всё сетевое оборудование

Пост про закупку. Точнее — про то, как выглядит нормальный разговор ИТ с деньгами компании.

Отправная точка

После истории с созвонами стало ясно: настройками мы выжали что могли, но само оборудование собрано из того, что было. Разные производители, разные поколения, никакого единого управления.

Хочешь поменять пароль от Wi-Fi — идёшь по всем точкам. Хочешь понять, где теряется трафик — не видишь картину целиком.

Что купили

Обновили инфраструктуру целиком на единой платформе: точки доступа, контроллер, коммутатор, маршрутизатор. Плюс телекоммуникационный шкаф и бесперебойник — чтобы всё это стояло не на подоконнике.

Сумма — 202 870 рублей.

Почему единая платформа

Главный аргумент был не в скорости, а в управляемости:

• настройки применяются везде сразу
• видно всю сеть на одном экране
• устройство при переходе между точками не рвёт соединение
• добавить точку — это подключить её, а не настраивать заново

Для отдела из одного-двух человек это не удобство, а вопрос физической возможности обслуживать сеть.

Вывод

Просить деньги нужно не на предмет, а на решение проблемы.

«Нужен новый роутер» — непонятно зачем, легко отложить. «Созвоны рвутся, потому что трафик не приоритизируется, а управлять текущим зоопарком мы не можем — вот что предлагаю и что это даст» — обсуждаемо.

И второе: перед закупкой мы сначала выжали из старого всё, что можно. Поэтому на разговор о деньгах я пришёл не с «давайте купим и посмотрим».

Бэкапы, камеры и серверная: работа, которой не видно

Про задачи, которые не выглядят достижением. По ним нет красивого «было/стало». Но из-за них однажды ничего не случится.

Бэкапы

Простой вопрос, на который в большинстве компаний нет ответа: что будет, если завтра у бухгалтера умрёт диск?

Не «у нас же всё в облаке», а конкретно: какие файлы пропадут, за какой период, сколько займёт восстановление.

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

Камеры

Камеры подключаются к облачному сервису по протоколу с паролем. Эти пароли ставятся при установке и потом живут годами.

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

Серверная

Физический доступ к оборудованию, к которому подключена вся компания, должен быть у ограниченного круга людей и должен фиксироваться.

Это не про недоверие. Это про то, что если что-то пойдёт не так, надо понимать, кто и когда там был.

Почему пишу

Эту работу невозможно продать как результат. «Сделал бэкапы» — и что? Ничего не изменилось.

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

Что можете сделать вы

1. Не хранить единственную копию рабочего файла у себя на компьютере
2. Сказать про доступ, которым не пользуетесь полгода
3. Написать, если увидели открытую серверную или незнакомого человека у оборудования

Забрать админ-права и не поссориться со всеми

Задача, которая технически делается за день, а по-человечески за месяц.

Что было

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

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

Что сделали

1. Забрали админ-права у клиентского отдела, закупок и бухгалтерии
2. Завели единую локальную учётку для ИТ — чтобы обслуживать машины, не возвращая права
3. Заодно посмотрели, что вообще установлено и в каком состоянии техника

Как это делалось на самом деле

Не «запустили скрипт». Прошёл по каждому человеку отдельно и записал результат в задачу: у кого исправлено, у кого нет, где администратор оказался непонятно кем и когда созданный.

Скучно, долго и никак иначе. Автоматизировать поиск того, чего не должно быть, нельзя — не знаешь заранее, что найдёшь.

Зато попутно стало видно реальное состояние парка. Отдельной задачи «провести ревизию» не понадобилось.

Про человеческую часть

Забрать права — это ухудшить людям жизнь. Раньше ставил программу сам, теперь надо просить.

Здесь важно не спорить, а признать: да, стало на шаг длиннее. Взамен компания перестаёт зависеть от того, насколько каждый из нас внимателен к письмам от незнакомцев.

И не оставлять людей без выхода: нужна программа для работы — ставим.

Вывод

Самые правильные ИТ-решения обычно делают жизнь чуть менее удобной. Это нормально. Ненормально — вводить их молча и потом удивляться сопротивлению.

Кто имеет доступ к чему

Про то, что происходит, когда человек уходит из компании.

Проблема

У сотрудника остаются: почта, Битрикс, RetailCRM, МойСклад, Usedesk, общие папки, Вики, иногда ключи от интеграций.

Пока нет единого списка, отключить всё можно только по памяти. Вспомнили пять систем — отключили пять. Про шестую вспомнили через полгода.

Проблема не в злом умысле. Проблема в том, что мы не знаем, что осталось открытым.

Что сделали

Собрали матрицу доступов: кто, в какие сервисы, с какими правами. Прошли по всем уволенным — закрыли учётки, сменили пароли там, где доступ был общим.

Дальше это стало частью процесса: приём и увольнение — отдельный тип задачи со своим чек-листом. Не «Маша уволилась, отключите почту», а полный проход по списку.

Побочный эффект, который окупил всю работу

Когда матрица появилась, я сверил её с таблицей оплат сервисов. Вопрос простой: за что мы платим и кто этим пользуется?

Нашлись сервисы, которые компания оплачивает, а не пользуется ими никто. Живые деньги каждый месяц.

Что это значит для вас

Когда я прошу подтвердить, нужен ли доступ — это не проверка. Лишний доступ лежит просто так и создаёт риск, ничего не давая взамен.

Отдельная просьба к руководителям: когда человек уходит, напишите в ИТ до последнего дня, а не после. В день увольнения мы успеваем закрыть всё аккуратно, через неделю — уже разбираемся.

Сколько мы платим за то, чем никто не пользуется

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

С чего началось

У ИТ есть таблица оплат сервисов: что, когда, сколько. Раз в период её нужно проверять, чтобы ничего не отключилось из-за просрочки.

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

Что сделали

Соотнесли два списка, которые до этого жили отдельно:

• таблица оплат — за что компания платит
• матрица доступов — у кого есть доступ и к чему

Ожидаемый результат сформулировали заранее: список сервисов, которые оплачиваем, но которыми никто не пользуется.

Что нашлось

Такие сервисы нашлись. Дальше по каждому уточнили у отделов, нужен ли он, и отключили оплаты там, где ответ «нет».

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

Почему это работает

Ни одна из таблиц по отдельности вопроса не задаёт. Бухгалтерия видит платёж и не знает, нужен ли он. ИТ видит доступы и не знает, сколько они стоят.

Вопрос появляется ровно тогда, когда данные оказываются рядом.

Вывод

Самые полезные находки чаще не в новых данных, а в соединении двух старых наборов, которые никто не сводил.

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

Если знаете, что отдел чем-то пользуется мимо ИТ — напишите. Вполне может быть, что мы платим за одно и то же дважды.

Ключи, которыми системы разговаривают друг с другом

Объясняю простыми словами вещь, которая обычно полностью невидима.

Что это такое

Когда заказ с сайта попадает в CRM, а из CRM в МойСклад — это не человек переносит. Системы разговаривают напрямую.

Чтобы одна пустила другую к своим данным, нужен пароль. Только не для человека, а для программы. Называется ключ или токен — длинная строка вроде «a7f3k9d2m5x8q1w4».

Таких ключей много: сайт и CRM, CRM и МойСклад, всё вместе и СДЭК, телефония, почта, банк.

В чём проблема

Ключи надо периодически менять: чем дольше живёт ключ, тем больше шансов, что он где-то утёк — в переписке, в скриншоте, у уволившегося сотрудника.

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

Замкнутый круг: не менять опасно, менять страшно.

Что сделали

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

Это разрывает круг. Смена ключа перестаёт быть сапёрной работой: открыл реестр, увидел три места, поменял во всех трёх, проверил.

Про хранение

Сами ключи не живут в переписке. Для них есть Passwork с личными и общими папками.

Когда я выдаю доступ, я кладу его в именную папку в Passwork, а не отправляю сообщением. Сообщение остаётся в истории чата навсегда.

Просьба

Если вам когда-то присылали пароль или ключ в личку — не пересылайте дальше и скажите мне. Перевыпустим и положим куда надо.

Заказ, который не доехал до склада

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

Симптом

Менеджер оформляет заказ на новый товар. В CRM он создаётся нормально. В МойСклад не попадает: не получает идентификатор ни через пять минут, ни через сутки.

При этом через другую карточку того же товара — работает.

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

И главное — в заявке было написано: такая же ошибка уже была при появлении дегидраторов и моющих пылесосов. Третий раз.

Разбор

Причина: товар не связан с системой МойСклад.

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

Не совпали идентификаторы → товар не находится → весь заказ не выгружается. Ломается одна позиция, а падает выгрузка целиком.

Почему повторялось

Потому что чинили следствие. Каждый раз конкретный товар исправляли, и на этом всё.

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

Что сделали

Вывели поле внешнего кода прямо в карточку товара в админке, чтобы заполнять вручную и не ждать. Автоматическую передачу поставили следующим шагом.

Разделение «сейчас разблокируем работу» и «потом уберём причину» здесь принципиально.

Вывод

Если проблема возникает при каждом появлении нового объекта — это не сбой, это дефект процесса создания.

И ещё: фраза «такое уже было с другими товарами» стоила дороже всего остального описания. Если что-то ломается не в первый раз — обязательно пишите об этом. Это меняет диагноз.

694 заказа, которые доехали, а система об этом не знала

История про то, как расходятся данные, если их долго не сверять.

Что обнаружилось

В CRM висели заказы в статусе «В доставке». Много. По данным курьерских служб они были давно вручены — клиент получил товар, всё в порядке.

Просто статус в нашей системе не обновился.

Почему это не косметика

От статуса зависит отгрузка в МойСкладе и, значит, учёт остатков. Плюс отчётность и понимание, какие заказы реально требуют внимания.

Когда в списке «в доставке» висят сотни заказов годичной давности, менеджер перестаёт на него смотреть. И настоящие проблемные заказы теряются среди мусора.

Разбор по перевозчикам

Причина — в сопоставлении статусов: у каждой службы свой набор состояний, и не все были сопоставлены с нашими.

• СДЭК — все заказы со статусом «Вручён» в личном кабинете перевели в «Выполнен». Это 694 заказа.
• Интеграл — сверились с техподдержкой, старые заказы закрыли.
• Почта России — сопоставили основные статусы вручения.

Разобрали около 90% проблемных заказов за прошлые периоды.

Что осталось

По Почте — 24 заказа, где нужно решение логиста. По СДЭКу — 64 с неочевидными состояниями вроде «Вручён (возврат)».

Это как раз тот случай, когда ИТ не решает само. «Вручён (возврат)» — это выполненный заказ или нет? Ответ зависит от того, как считает бухгалтерия.

Вывод

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

Разовая чистка — лечение симптома. Настоящее решение — сопоставить все статусы всех перевозчиков один раз и полностью, включая редкие.

Если видите заказ, который явно доставлен, а висит «в доставке» — скиньте номер. Один такой обычно значит, что есть ещё сто.

Почему заказ уехал не той службой

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

Что происходит сейчас

Заказ с сайта приходит в CRM, и тип доставки почти всегда один и тот же — по умолчанию. Даже если клиент выбрал другое.

Менеджер открывает заказ и правит руками. До десяти заказов в день на человека. Каждый раз одна и та же операция — и точка, где легко ошибиться.

Что предлагалось

Правила выглядели понятно: тип доставки передаётся с сайта как есть; если курьер — служба определяется по региону; при смене типа нерелевантные поля очищаются сами.

Сначала пробовали решить на стороне CRM. Не получилось — слишком много неучтённых частных случаев.

Где задача застряла — и почему это правильно

Когда пришли с этим к коллегам, прозвучал разворачивающий вопрос.

Смысл: задача выглядит сложной, потому что у нас слишком много «но». Сначала нужно определить регламент отправки — правила, схему, — и только потом накручивать логику. Иначе упрёмся ровно в то же, во что упёрлись в CRM.

И ключевое: нужно, чтобы все менеджеры работали по единым правилам. Чтобы при отправке в город А любой выбирал одну и ту же службу.

Что это значит

Мы пытались автоматизировать правило, которого не существует в письменном виде.

Каждый менеджер выбирал службу по опыту: где дешевле, где быстрее, где меньше проблем в этом регионе. Опыт у всех разный. Автоматизировать разный опыт нельзя.

Вывод

Если процесс нельзя описать словами — его нельзя автоматизировать. Программа не умеет «как обычно делают».

Поэтому задача сейчас не в разработке, а в согласовании правил. Выглядит как простой, а на самом деле это и есть работа.

Если у вас есть личные правила выбора службы — напишите в комментарии. Из этого и получится регламент.

Адрес, который CRM понимает

Про то, почему «просто текст» — это проблема.

В чём дело

Когда клиент оформляет заказ, адрес уезжает в CRM обычной строкой: «г. Москва, ул. Ленина, д. 5». Для человека это адрес. Для системы — набор символов.

CRM не понимает, что «Москва» — это регион с определённым номером в справочнике. А без этого не работает автоматическое определение тарифов: система не знает, куда именно едет посылка.

Почему это ощущается в работе

Когда я описывал задачу, был справедливый вопрос: ну не распознаёт — и что?

Ответ дали коллеги, и он оказался конкретнее моего:

• менеджерам приходится каждый раз очищать поле адреса и вводить заново
• на выбор региона завязано определение местного времени клиента

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

Что нужно технически

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

Разговор, который мне понравился

Когда задача пошла на согласование, вопрос от руководителя был не «сколько стоит», а другой:

«Ты знаешь, как решить эту задачу и сделать так, чтобы решение было легко поддерживать? Если да — берём в работу».

Правильный вопрос, я его записал.

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

Тестовый заказ: как проверять и ничего не сломать

Практический пост. Пригодится всем, кто хоть раз хотел «посмотреть, что будет, если нажать».

Зачем

Любое изменение в CRM, на сайте или в бизнес-процессе надо проверять. Не «по логике должно работать», а увидеть глазами.

Проверять на настоящих заказах нельзя: настоящий заказ — это реальный клиент, деньги и отгрузка со склада.

Что описано в Вики

1. Создание заказа в МойСкладе
2. Создание заказа в CRM с нуля, а не копированием
3. Создание тестового клиента
4. Уценка — у неё особый способ оформления

Инструкция живёт в разделе ИТ-отдела и обновляется, когда меняется процесс.

Почему «с нуля, а не копированием» — самое важное

Самая частая ошибка при тестировании — взять похожий заказ и скопировать.

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

Тест должен повторять путь клиента, а не путь копипаста.

Кому это нужно

Не только ИТ. Если вы руководитель и хотите проверить новую механику перед тем, как дать её команде — это ваш инструмент. Ждать нас не нужно.

Правила хорошего тона

• Тестового клиента называть явно тестовым именем, не «Иван Иванов»
• После проверки заказ закрывать, чтобы не попал в отчётность
• Если тест затрагивает отгрузку — предупредить склад

Если пользуетесь инструкцией и чего-то не хватает — напишите. Она для того и лежит в Вики, чтобы дополняться.

Сообщения от клиентов, которые не доходили

Самая неприятная категория проблем — та, где вы не знаете, что проблема есть.

Что случилось

Клиентка ответила на вопрос специалиста через две минуты. Сообщение не дошло. Отобразилось только следующее — на следующее утро.

То есть клиент ответил быстро, а с его стороны выглядело так, будто мы сутки молчали.

Почему это критично

Разберём глазами клиента. Он написал. Ответа нет. Он не знает, что сообщение потерялось технически — он думает, что его игнорируют.

Дальше два варианта: написать ещё раз раздражённо или уйти.

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

Где ломается

Проблема в длине цепочки. Сообщение проходит несколько независимых звеньев: мессенджер → промежуточный сервис интеграции → платформа поддержки.

Каждое звено — отдельная компания и отдельная точка отказа. И на качество этих звеньев мы не влияем. Можем только писать в поддержку и ждать.

Что делаем

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

Второе — сокращать цепочку там, где можно, и давать заботе прямой доступ в мессенджер.

Что можете сделать вы

Если видите, что сообщение пришло с задержкой или между репликами явный провал по времени — приложите ссылку на чат и время и заведите задачу.

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

WhatsApp Business и WABA — почему это две разные вещи

Пост-объяснение. Почему на «дайте прямой доступ в мессенджер» ответ у Telegram и WhatsApp разный.

Откуда взялся вопрос

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

Разбирались, что реально возможно.

Telegram — можно

Прямой доступ включили.

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

Удобство есть, но история переписки становится менее прозрачной. Это осознанный размен.

WhatsApp — надо различать два подключения

WhatsApp Business — отдельное мобильное приложение из магазина, для малого и среднего бизнеса. Подключается телефоном. Один аккаунт работает максимум на четырёх устройствах.

WhatsApp Business API (WABA) — это не приложение. Это программный интерфейс. Зайти в него человеком нельзя в принципе: там нет окна с перепиской.

Разные продукты с похожими названиями. Решение, которое работает для одного, для другого физически не существует.

Итого

• Telegram — прямой доступ сделали
• WhatsApp Business — возможен, но упирается в лимит устройств: у нас уже подключено максимальное количество
• WABA — невозможен, и это не вопрос настроек или тарифа

Зачем пишу

Затем, что «дайте доступ в ватсап» — это на самом деле три разных запроса, и ответ на каждый свой.

Когда ИТ говорит «так нельзя», за этим не всегда стоит нежелание. Иногда — устройство продукта, которое мы не выбирали.

Что отвечает клиенту в четыре утра

Маленькая задача с большим эффектом.

Постановка

Отдел заботы работает не круглосуточно. Клиенты пишут круглосуточно.

Запрос простой: сделать автоматический ответ на время, когда отдел не работает — с 21:00 до 9:00.

Почему это важнее, чем выглядит

Клиент, который пишет в 23:40, не знает нашего графика. Он знает только, что написал и ему не ответили.

Дальше в его голове одно из двух: «они не работают, напишу утром» или «им всё равно». Разница между этими мыслями — одно сообщение.

Автоответ не решает проблему клиента. Он снимает неопределённость. Человек понимает, что сообщение получено, и перестаёт ждать.

Что важно не испортить

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

Поэтому текст правили отдельно и довольно долго. Хороший ночной автоответ должен:

• сказать, что сообщение получено
• назвать конкретное время ответа, а не «в ближайшее время»
• не притворяться живым человеком
• по возможности дать что-то полезное прямо сейчас

Побочный эффект для команды

Без автоответа утренняя смена открывает переписки, где клиент писал в час ночи и ждёт с тех пор. Разговор начинается с извинений.

С автоответом клиент уже знает, что происходит, и утро начинается с сути вопроса, а не с починки настроения.

Вывод

Есть класс задач с очень высоким отношением пользы к трудозатратам: ночной автоответ, статус заказа по ссылке, подтверждение о получении.

Все они делают одно — убирают ощущение, что человек кричит в пустоту.

Если у вас есть момент, где клиент или коллега остаётся без ответа и не понимает почему — напишите. Скорее всего, это чинится за час.

ИИ слушает сто звонков в день. Мы смотрим на цифры

Разбор проекта, который сейчас на финишной прямой.

Запрос

Нужен дашборд по чек-листу качества обслуживания: видеть, насколько менеджеры соблюдают стандарт разговора, не переслушивая сотню звонков руками.

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

И честное наблюдение: сотрудники часто не прощаются — а может, это нейросеть не распознаёт прощание?

Именно это сомнение потом оказалось ключевым.

С чего начал

Не с дашборда. Собрал первую версию в обычной таблице: чек-лист по каждому менеджеру, отмеченный руками по реальным звонкам.

Смысл — до всякой автоматизации договориться, что именно мы считаем. Показал, обсудили, идея подошла. Только потом пошёл строить.

Правило, которого стараюсь держаться: если не можешь посчитать метрику руками на десяти примерах — автоматизировать её рано.

Что получилось

• Средний процент выполнения чек-листа по каждому менеджеру
• Клик по менеджеру — детализация, по каким пунктам просел
• Разделение по отделам: пункты 1–6 общие, 7–11 рекламации, 12–18 продажи
• Динамика по дням

Было / стало

• Оценка качества: выборочно, руками, десяток звонков → все звонки за период
• Разбор с менеджером: «мне кажется, ты...» → конкретный пункт и конкретный звонок
• Отчёт руководителю: собирается вручную → открывается по ссылке

Что это значит для менеджеров

Это не про «поймать и наказать». Чек-лист показывает конкретные пункты, которые проседают — не проговорили сроки, не уточнили модель. Их можно поправить за один разговор с руководителем.

А про сомнение в достоверности — оно оказалось полностью оправданным. Про это следующий пост.

Промпт, который применяется только к новым звонкам

Самый полезный провал за последнее время.

Что случилось

Собрал первую версию дашборда качества, показал руководителю отдела заботы.

Реакция была прямой: такой низкий процент не может быть правдой, где-то ошибка.

Это правильный ответ. Не «спасибо, красиво», а сомнение в цифре — потому что человек знает свою команду и видит, что данные не сходятся с реальностью.

Первая причина

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

А работала фактически общая логика. Нейросеть отвечала честно — её просто плохо спросили. Переписал.

Вторая причина, и вот она серьёзная

Обновлённый промпт применяется только к новым звонкам. Старые остаются с оценками по старой логике. Пересчитать историю нельзя.

Сколько бы я ни улучшал формулировки, всё, что разобрано раньше, остаётся оценённым неправильно.

Почему это меняет проект целиком

Дашборд качества — инструмент про динамику. Смысл в том, чтобы сравнивать: стало лучше или хуже.

Если часть периода посчитана по одной логике, а часть по другой — сравнивать нельзя. График покажет рост или падение, которого не было: просто сменилась линейка.

И это невидимо. График рисуется, цифры красивые, никто не догадается.

Что сделал

Зафиксировал дату, с которой данные считаются достоверными. Всё, что раньше — справочно, но не для выводов о людях.

Неприятное решение: накопленную историю мы теряем. Но альтернатива хуже — принимать решения по сотрудникам на основе цифр, посчитанных по-разному.

Вывод

Прежде чем строить что-то на данных внешнего сервиса, задайте один вопрос: что произойдёт с уже посчитанными данными, если изменить правила подсчёта?

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

И отдельно: этот баг нашёл не я и не тесты. Его нашёл человек, который сказал «не верю этой цифре». Ощущение, что цифра странная — это полноценный баг-репорт.

AI-ассистент, который разбирает заявку до человека

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

Идея

К первому касанию менеджера обращение уже должно быть проанализировано. Не «принято в работу», а разобрано: есть гипотезы, в чём проблема, и предложены решения.

Разница принципиальная. Первое — вежливость. Второе — работа.

Как выглядит

Приходит заявка в поток ИТ. Через некоторое время в задаче появляется разбор:

• Кратко — суть обращения в несколько строк
• Проблематика — в чём собственно проблема, а не что человек написал
• Сотруднику — нужно уточнить — конкретные вопросы, без ответа на которые задачу не сделать
• Что уже сделано и что осталось — если в задаче была переписка

Самая ценная часть — третья.

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

Ещё одна деталь

Отдельно подтянули каналы оповещений внешних сервисов — CRM, платформы поддержки, телефонии. Чтобы понимать: заявка «у меня не работает» — это наша поломка или у провайдера массовый сбой.

Разница в реакции колоссальная. В первом случае надо чинить, во втором — предупредить всех и ждать.

Как доводили

Собрал первую версию, перевёл на более умную модель и на наш сервер. Дальше не стали додумывать, а начали собирать реакцию на реальных задачах.

Через несколько дней получил конкретный список правок и внёс их. Потом ещё пару дней отслеживали на живых задачах.

Что решили дальше

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

Улучшать ассистента по ощущениям «вроде хуже стал отвечать» бессмысленно. Нужна выборка реальных обращений и его ответов.

Что это значит для вас

Если в вашей задаче появился разбор от робота — это не отписка. На вопросы в блоке «нужно уточнить» стоит ответить: они сформулированы под вашу проблему и экономят день переписки.

А если разбор откровенно мимо — скажите. Это ровно та фактура, которая нужна.

Не трогай тело задачи: правило важнее нейросети

Продолжение про AI-ассистента. Про ограничения, которые мы ему поставили.

Соблазн

Когда есть нейросеть, понимающая текст задачи, возникает желание: пусть наведёт порядок. Перепишет кривое название. Дополнит описание. Переставит стадию. Проставит приоритет.

Технически всё это возможно и выглядит полезно.

Почему отказались

Правки от коллег были конкретными:

1. Не удалять тег поддержки
2. Не менять пометку потока в названии
3. Все изменения — отдельным блоком, тело задачи не трогать
4. Стадию не менять: иначе задача может потеряться
5. В уведомление отдавать ссылку, а не идентификатор
6. Ожидаемый результат не менять

И общий вывод, который я считаю ключевым:

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

Почему это точное рассуждение

У комментария есть автор, время, и он неизменен. Его можно прочитать через полгода и понять, кто написал и когда.

У описания задачи истории изменений нет. Если робот его отредактировал, вы видите только результат. Что было изначально — не восстановить.

Представьте спор через месяц: «мы договаривались о другом». Открываем задачу — а там текст, который частично написал человек, частично дописала нейросеть, и отличить невозможно.

Общее правило

Автоматика может добавлять, но не должна переписывать.

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

И про стадии

Запрет двигать стадию сначала казался мне избыточным. А смысл вот в чём: стадия — это то, по чему люди глазами отслеживают работу. Если её двигает не человек, доска перестаёт отражать реальность, и задача может тихо уехать туда, где на неё никто не смотрит.

Автоматизировать можно то, что видно. Незаметные автоматические изменения — самый быстрый способ потерять доверие к системе.

Робот Wollmer: три бага, которые чуть не убили доверие

Про то, как автоматика зарабатывает и теряет право на существование.

Что делает Робот

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

Блок истории — самое недооценённое. Открываешь задачу месячной давности и за пять секунд видишь весь её путь вместо сорока комментариев.

Баг первый: кричал «волки»

Робот писал в чат «поступила новая задача». Но уведомление срабатывало не только на создание — ещё на смену стадии и на паузу.

В чат шёл поток «новых задач», которые новыми не были. Через неделю на такие уведомления перестают смотреть — причём на все, включая настоящие.

Исправили: исключили все события, кроме реального создания.

Баг второй: молчал, когда был нужен

Дважды приходила жалоба: задача подошла к сроку, а предупреждения не было. И происходило это выборочно.

Такое опаснее полного отказа: если робот не работает вообще — ты проверяешь сам. Если работает через раз — полагаешься и обжигаешься.

Критерий приёмки сформулировали жёстко: присылает в 100% случаев, без исключений.

Баг третий: подписывал меня вместо себя

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

Мне написали прямым текстом — верните робота, иначе Миша будет путаться. Разобрал механику отдельной задачей.

Вывод

Если робот шлёт лишнее — его отключают в голове, и вместе с шумом теряется полезное. Если иногда молчит — на него не полагаются и всё равно проверяют руками.

Ценность появляется только при полной предсказуемости.

Что дальше

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

Хотите Робота в свой поток — напишите, какой первый ответ должен получать человек, который к вам обратился. Не «уведомление о принятии», а текст. Соберу и раскатаю по очереди)

Вики как данные

Про то, как база знаний перестала быть просто набором страниц.

Три задачи, которые оказались одной

За несколько месяцев пришли три разных запроса.

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

Второй. Выгрузка структуры целиком, включая закрытые блоки.

Третий. Доступ к выгрузке открытых разделов — чтобы сделать аналитику по ролям: кому какие инструкции изучить.

Три заказчика, три цели. Общее одно: всем нужна база знаний не как сайт, а как данные.

Почему это не одно и то же

Вики устроена для чтения человеком: зашёл, нашёл, прочитал.

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

Ни одну из них нельзя решить, открывая страницы по одной.

Как уточнял задачу

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

1. Выгружать закрытую структуру вместе с вложениями или достаточно папок?
2. Страницы в текстовом формате устроит или нужен PDF со скриншотом?

Разница огромная. Текст — это данные: искать, сравнивать, анализировать. PDF со скриншотом — картинка, красивая и бесполезная для анализа.

Люди часто просят «выгрузку», подразумевая разные вещи. Полминуты на уточнение экономят день работы не в ту сторону.

Вывод

Когда одна и та же просьба приходит от трёх разных людей с разными целями — это не три задачи. Это одна инфраструктурная задача, которую надо решить один раз и нормально.

Их легко проглядеть: каждая по отдельности выглядит мелкой и частной.

Телеграм-бот для сервисных центров

Проект, где интереснее всего оказалась подготовка, а не сборка.

Задача

Авторизованные сервисные центры чинят технику Wollmer. Им регулярно нужно одно и то же: заказать запчасть, узнать где посылка, уточнить статус ремонта, позвать менеджера.

Всё шло через менеджера вручную. Менеджер — узкое место: он в отпуске, на обеде, отвечает третьему по счёту.

Схему бота описал Даниил Агеев, собирал и связывал с CRM я.

Что умеет

1. Сделать заказ — ведёт в магазин запчастей
2. Указать телефон — авторизация по номеру, дальше кнопка становится профилем
3. Отследить заказ — бот сам запрашивает статус в CRM
4. Позвать менеджера — помечает диалог как требующий внимания
5. Список заказов — история по конкретному центру

Плюс бот пишет первым: появился трек-номер — присылает вместе с датой доставки; техника ушла в ремонт — спрашивает дату выдачи; ремонт гарантийный — просит акт приёма-передачи.

Главный вопрос, решённый до сборки

Даниил задал вопрос, от которого зависела вся архитектура: можно ли из CRM отправлять вызовы в бота? Не бот спрашивает CRM, а CRM в нужный момент говорит боту «сделай это у клиента».

Без этого получился бы обычный бот-меню. С этим — бот сам начинает разговор в нужный момент.

Пошёл читать документацию платформы и выяснил: возможность есть, но доступна только на определённом тарифе. То есть вопрос упирался не в разработку, а в подписку.

Написал в задачу ровно это. Даниил параллельно уточнил у поддержки — сошлись на одном ответе с двух сторон.

Почему пишу

Самая частая причина, по которой проект встаёт на середине — ограничение, обнаруженное на середине. «Мы уже всё сделали, а оказалось, что так нельзя».

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

Если у вас есть вопрос, который задают одинаковыми словами по десять раз в день — напишите. Скорее всего, это можно отдать боту)

Куда делся файл «себестоимость»

Короткая детективная история с моралью, которая касается каждого.

Что случилось

В работу пришло сообщение: пропала таблица с себестоимостью всех товаров.

Подробности тревожные. Сначала файл пропал. Потом ссылка на него неожиданно открылась из истории браузера — то есть файл существовал. Ссылку сохранили в задачу. А на следующий день перестала работать и она.

Ключевая деталь

Сотрудница, которая вела таблицу, уволилась.

Первый вопрос в такой ситуации: файл лежал на личном диске или в общем корпоративном пространстве?

Это определяет всё. Файл в общем пространстве принадлежит компании и остаётся при увольнении. Файл на личном диске уходит вместе с учётной записью — и когда её отключают по регламенту, документы перестают быть доступными.

Чем закончилось

Файл нашли, ссылку на документ и выгруженную папку приложили в задачу. В этот раз повезло.

Почему «повезло» — не стратегия

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

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

Получается конфликт: ИТ правильно закрывает доступы уволенного, и одновременно компания теряет документ. Оба действия корректны, результат плохой.

Что из этого следует

1. Рабочие документы живут в общем пространстве, а не на личном диске. Даже черновики, если ими кто-то пользуется
2. Если документом пользуются несколько человек — у него должно быть постоянное место, а не ссылка в переписке
3. При увольнении вопрос «какие рабочие файлы он вёл» задаётся до последнего дня

Третий пункт мы теперь включаем в процесс.

Просьба

Посмотрите прямо сейчас: есть ли у вас рабочий файл, который существует только у вас? Если да — перенесите в общее пространство. Не знаете куда — напишите, подскажу.

Что дальше

Финальная статья блога. Всё выше — полтора года работы. Здесь то, что впереди.

Единая точка входа

Самое крупное из запланированного. Сейчас у каждого отдельный логин в Битрикс, Яндекс, RetailCRM, МойСклад и Usedesk. Пять паролей, пять сроков смены, пять мест, где можно ошибиться.

Цель — один вход на всё. Для вас это один пароль вместо пяти. Для компании — возможность отключить человека одним действием.

Возвраты — довести до конца

Живой прогон полной цепочки на реальном клиенте, перевод авторства сообщений на Робота, автоотправка клиенту трек-номера и платёжки прямо в чат, дашборд по возвратам. Эти данные сейчас никуда не выгружаются — беру на себя.

Качество звонков

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

AI-ассистент — вторая итерация

Соберём выгрузку реальных обращений и его разборов, посмотрим, где он попадает, а где мимо. И только потом будем менять.

Автовыбор доставки

Ждём регламент отправки — единые правила, по каким городам какой службой. Без этого автоматизировать нечего.

Четыре просьбы к вам

1. Лишние доступы. Не пользовались сервисом полгода — напишите. Это уборка риска, а не проверка
2. Файлы в единственном экземпляре. Проверьте, нет ли рабочего документа только у вас на компьютере
3. Робот в свой поток. Напишите, какой первый ответ должен получать человек, который к вам обратился
4. Повторяющиеся вопросы. Задают одно и то же по десять раз в день — расскажите

И главное

Этот канал существует, чтобы решения ИТ перестали выглядеть как погода — что-то, что просто случается с вами.

Почти всё, что описано выше, началось с того, что кто-то не поленился написать подробно: со временем, ссылкой и скриншотом. Клиент, который звонил тридцать минут в пустоту, найден так. Заказ, который не доехал до склада — так же.

Пишите в комментарии. Спорьте. Особенно если считаете, что решение неудобное)

1472 задачи за полтора года

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

Раз уж такой повод, решил закончить блог цифрами. Выгрузил все свои задачи и посчитал.

Что получилось

• 1472 задачи закрыто с марта 2025 по август 2026
• Самый плотный месяц — 133 задачи за июль 2025
• Ещё 1002 задачи за это время поставлено коллегам

Из чего они состояли

• 171 — бизнес-процессы и автоматизация
• 169 — CRM, склад и доставка
• 168 — техника и рабочие места
• 115 — доступы и учётные записи
• 98 — оплаты и документы по сервисам
• 81 — данные, дашборды и ИИ
• 71 — сеть и инфраструктура
• 65 — телефония
• 62 — Вики и регламенты

И самое интересное

Доля задач «починить железо» упала с 22% до 6%. Доля «настроить и перестроить процесс» выросла с 7% до 23%.

А на каждую задачу, поставленную коллеге, в начале 2025 приходилось 12 закрытых своими руками. Сейчас — 6.

Что за этим стоит

За каждой из этих задач — чья-то заявка. Кто-то не поленился написать, что не работает, приложить скриншот и ответить на уточняющие вопросы.

Меня в поздравлении назвали человеком, к которому приходят с болью и уходят с решением. Это очень точно про то, что мне нравится в работе. Но работает это только в обе стороны: без ваших подробных заявок половина этих задач так и осталась бы «ну там что-то глючит».

Так что спасибо за поздравления — и спасибо за задачи. Продолжаем)