Качество техподдержки падает из-за нейросетей

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

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

Честно говоря, это не только про вендоров. Та же тенденция есть в любой IT-техподдержке — от SaaS-сервисов до внутренних helpdesk, ну и Сбер тоже не исключение. На мой взгляд, причин несколько:

• Сокращение расходов и оптимизация штата. А это уже следствие подключения к техподдержке нейросетей. Руководство видит возможность сократить затраты (считай, заработать).

• Ставка на «среднего» специалиста, а не эксперта. Задумка хорошая, что средний спец + нейросеть = эксперт, но вот на практике это почти всегда не так.

• Увлечение автоматизацией и «ботизацией» без продуманной логики. Нейросети поумнели, и почему бы их не использовать на полную катушку?

После появления в техподдержке LLM многое поменялось. В теории отличная штука: нейросеть может за секунды найти ответ в базе знаний. На практике мы получаем красивый текст (или голос), который звучит как решение, но не решает проблему, а заставляет обратившегося клиента уточнять какие-то вопросы, повторять одно и тоже, как попугай, и каждый раз начинать диалог заново. Так происходит потому что:

• Модель не понимает контекст, если вопрос нестандартный.

• Она «галлюцинирует» там, где не знает ответа.

• Клиент тратит время на проверку, а не на решение.

Я думаю, что ситуация будет усугубляться: всё больше компаний будут пытаться экономить, заменяя первую линию поддержки на чат-бота с LLM. Это общий тренд. И вместо того, чтобы решить проблему за 10 минут с инженером, клиент будет три раза «объяснять заново», прежде чем добьётся связи с человеком.

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

Я думаю вот о чем:

1. LLM как ассистент, а не как фронт. Модель подсказывает оператору варианты решения, а не отвечает напрямую клиенту.

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

3. Контекст — главное. Не подсовывать LLM голый вопрос, а давать историю обращений, конфигурацию системы, логи.

4. Метрики качества. Замерять не скорость ответа, а количество обращений, которые закрыты «с первого раза».

Вопрос в том, когда и как компании это будут делать правильно? Потому что гонка «а сэкономим-ка ещё бюджет» легко превратит службу поддержки в чат, от которого клиент убегает к конкурентам.

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

Было бы интересно обсудить с теми, кто из ИТ, как это организовано у Вас с техподдержкой? Да и вообще, кто что думает по этому поводу?

---

Понравилась моя аналитика? В моем ТГ канале Код ИТ-директора я гораздо чаще делюсь подобными мыслями, короткими кейсами и полезными инструментами, которые не всегда доходят до формата большой статьи.

Там — больше «живых» заметок из окопов управления IT-бизнесом и возможность напрямую задать вопрос.

Подписывайтесь, что бы получать больше инсайтов без воды Тыц

Переход 1С на PostgreSQL и прогнозы до 2031 года

Ни для кого не секрет, что клиент‑серверный вариант 1С изначально затачивался под MS SQL. Вспоминаю год 2017-й и точно помню, что в тот момент Postgres ставили в основном те компании, которые хотели сэкономить. Плевались, но использовали. Чуть более или менее серьезная нагрузка — и всё.

Помню, как мы для «Управления IT‑отделом 8» написали расчет SLA по графикам техподдержки. На файловой базе и в MS SQL все работало прекрасно. Выпустили обновление, но один клиент на Postgres начал жаловаться. Долго выясняли, в чем дело. В конечном итоге я подключился к нему на тестовый сервер, прошелся отладчиком и… бинго! Действительно наша ошибка: не указали сортировку в одном из вложенных запросов. На файловой и на MS SQL такой запрос, повторю, работал отлично. Postgres в этом деле оказался строже — сказано в документации, что выборка не гарантирует порядок? Будьте добры предусмотрите это.

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

Если коротко, то вот главные грабли, на которые наступают при миграции 1С на PostgreSQL:

Проблема № 1: Деградация производительности. Миграция «в лоб» почти всегда приводит к проблемам с блокировками и работой планировщика запросов. Приходится переписывать код и оптимизировать его под PostgreSQL. Возможно, даже менять что‑то в самой платформе.

Проблема № 2: Кадры. Найти опытного DBA по Postgres, который глубоко понимает специфику 1С, значительно сложнее и дороже. С MS SQL всё было проще: установил, клик, клик — готово. Даже без тонких настроек многое работало «из коробки».

Ну и самое главное: миграция — это не просто смена СУБД. Это полноценный проект, требующий тестирования, переписывания узких мест в коде и, возможно, обучения команды. Экономия на лицензиях может быть полностью съедена затратами на внедрение и поддержку (да и не сказал бы, что тот же Postgres Pro дешевый).

А теперь о том, почему этот разговор вообще имеет смысл.

Раньше мы всегда советовали клиентам MS SQL как надежную и проверенную СУБД. Да, в 2015-м появился платный Postgres Pro, но, честно сказать, мы его всерьез не рассматривали. Зачем, если есть деньги на проверенный MS SQL? А если хотелось сэкономить — был бесплатный Postgres со всеми его тогдашними особенностями.

Но потом пришел 2022-й год, санкции вендоров и постепенная миграция стала трендом. А сейчас это уже не вопрос выбора, а вопрос времени.

Это не просто ощущения, это подтверждают цифры из исследования ЦСР.

Уже в 2024 году на новые продажи зарубежного ПО пришлось всего ~10% рынка. Прогноз до 2031 года следующий: российские решения для работы с базами данных могут занять до 99% новых продаж (!) Процесс импортозамещения будет идти, а если мы берем 1С, то тут в выигрыше PostgreSQL/Postgres Pro. Причины понятны: уход западных вендоров, требования регуляторов и развитие отечественных продуктов.

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

У меня вопрос. Планируете переход на PostgreSQL или, как и мы, пока живете на старом софте?

‑-

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

30 лет без дизайна и миллиард в кассе

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

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

Для тех, кто не в курсе: Craigslist - это что-то типа Авито, но в США, т.е. такая гигантская доска объявлений. Ее дизайн застрял где-то в 1998 году: синие ссылки, простейшая верстка, ноль графики. По любым современным меркам UI/UX - это катастрофа. При этом компания с крошечной командой зарабатывает сотни миллионов (а по некоторым оценкам - более миллиарда) долларов в год. Работает там от силы 50 человек (!) Если пересчитаем выручку, то окажется, что на каждого сотрудника приходится 4 млн. долларов в год (!) Очень круто!

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

Почему этот «примитивный» дизайн работает и приносит миллиарды?

1. Скорость. Сайт загружается мгновенно. Нет тяжелых фреймворков, мегабайтов JavaScript и аналитических скриптов. Чистая функция.

2. Плотность информации. Никаких баннеров, всплывающих окон и модных карточек. Только текст и ссылки. Вы видите максимум полезной информации на одном экране.

3. Отсутствие трения. Хочешь разместить объявление? Нажимай и размещай. Не нужна регистрация (как я понял), подтверждение почты и двухфакторная аутентификация, чтобы продать старый стул. Сервис не мешает тебе делать то, зачем ты пришел.

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

Мой «улучшенный» форум вводил трение: регистрация, создание тем, сложная структура. Я убил легкость и анонимность. Точно так же любой «современный» редизайн Craigslist с React, модными анимациями и персонализацией убьет его главное преимущество - скорость и простоту.

Вывод для любого IT-руководителя:

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

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

А в вашей практике есть свой внутренний «Craigslist»? Старый, неудобный, но незаменимый сервис, который все мечтают переписать, но боятся трогать?

---

Понравилась эта история? Это пример того, как я анализирую ошибки и извлекаю из них практические уроки. В моем ТГ канале Код ИТ-директора я гораздо чаще делюсь подобными мыслями, короткими кейсами и полезными инструментами, которые не всегда доходят до формата большой статьи.

Там — больше «живых» заметок из окопов управления IT-бизнесом и возможность напрямую задать вопрос.

Подписывайтесь, что бы получать больше инсайтов без воды Тыц

Эффект «стены Дурова», который я открыл за 10 лет до самого Дурова

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

2004 год. Я на 3-м курсе факультета прикладной математики и информатики АГУ (г. Майкоп), параллельно работаю программистом в математической школе при университете. Моя вотчина — программа для подсчёта рейтингов учеников, набор текстов для методичек и небольшой сайт с гостевой книгой.

Кто не застал — гостевая книга тогда была чем-то вроде бесконечного чата без регистрации. У детей мат. школы в ней кипела жизнь: по 100–200 сообщений в день (иногда даже больше), свои шутки, обсуждения задачек, разговоры «за жизнь». Формат был простой и лёгкий — написал ник, сообщение, и готово.

А я молодой, амбициозный и несу людям счастье)))

Я тогда подумал. Почему они мучаются с этим бесконечным тредом сообщений? Это же жутко неудобно! А что если я уберу эту гостевую книгу и заменю ее на удобный форум для своих? Хорошая же идея? Ну, если судить логически, то да. Свой форум, регистрация, понятно, кто пишет, можно делать свои темы и не тонуть в бесконечной беседе. На тот момент мне казалось, что это отличная идея сделать жизнь определенного круга людей лучше.

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

Догадываетесь, что было дальше? )))

Правильно. Провал… Ученики не стали использовать новый форум!

Была попытка одного человека что-то написать, но когда никто не ответил, то и он перестал что-то писать + пара регистраций пользователей. Моя попытка это исправить ни к чему не привела. Я даже старые сообщения пользователей из гостевой книги загрузил в новый форум. Все бестолку. Сайт, у которого был отличный трафик, буквально за неделю перестали посещать.

Для меня это было потрясение. Как так вообще? Я же хотел сделать как лучше для пользователей! Почему они не стали использовать новый форум?

Рефлексия и мои мысли на эту тему прилагаются:

• Новый форум не взлетел, т. к. старый был ламповый, легкий. Можно добавить одну запись под ником «Препод такой-то», а следующую «Иванов Иван». Было интересно переписываться в таком легком формате. Был вайб от использования такого формата. Может, помните в VK знаменитое: «Дуров, верни стену!»? Этот косяк Павла из той же оперы.

• Если какой-то сервис работает хорошо, но, на твой взгляд, там все организовано очень нелогично, не надо это исправлять сию минуту! Надо сделать опрос, проверить гипотезы, попробовать узнать мнение пользователей. Бывает, конечно, и такое, что пользователи не могут тебе сказать, что нужно добавить, и при добавлении этого «чего-то» оно действительно взлетает, но делать это нужно аккуратно, просчитывая варианты.

• Этот студенческий урок 20-летней давности я вспоминаю до сих пор каждый раз, когда моя команда предлагает «быстро улучшить» какой-нибудь работающий модуль. Часто при взгляде на проблему задаю себе вопрос: «Какую настоящую работу выполняет для пользователя этот старый, неудобный, но привычный функционал? И не убьем ли мы ту самую "ламповость", просто заменив ее на "правильное" решение?»

Вот такая история.

P. S. Если кто-то читает мой пост из тех, кто тогда сидел в этой гостевой книге, прошу у вас прощения. Я не хотел, чтобы так все вышло.

---

Понравилась эта история? Это пример того, как я анализирую ошибки и извлекаю из них практические уроки. В моем ТГ канале Код ИТ-директора я гораздо чаще делюсь подобными мыслями, короткими кейсами и полезными инструментами, которые не всегда доходят до формата большой статьи.

Про сотрудника Игоря, или про того, кто ни в чем никогда не виноват

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

Это был человек, который всегда делал работу только так, что у него не было никаких вариантов для самостоятельного принятия решений. Если ему что-то непонятно (даже по мелочи), он всегда подходил и спрашивал, как быть. Если есть несколько вариантов решения задачи, он озвучит все варианты и оставить выбор за мной.

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

Причём если ошибка была в коде, который он написал. Игорь каким-то волшебным образом умудрялся всегда находить слова типа: «А вот помнишь, ты мне говорил вот это сделать, я так и сделал, и вот в результате появилась ошибка». Иногда доходило до смешного: на форме при разработке были какие-то орфографические ошибки, и он начинал юлить. )) Мне в какой-то момент даже стало интересно, а в принципе он может сказать: «Я сделал здесь ошибку». И знаете что? За 5 лет работы с ним я так и не добился такого признания.

Что еще было: был сон на рабочем месте в рабочее время, несколько жестких будунищ после выходных, и в таких случаях я всегда его отправлял домой, потому что толку от такого сотрудника нет никакого (это другая история). Но нет. Он никогда не виноват. )))

Минутка рефлексии и мои рассуждения по поводу таких сотрудников:

1. Сотрудник, не берущий на себя ответственность, обходится компании дороже, чем кажется. Его реальная стоимость — это не только его зарплата, но и десятки часов моего времени как руководителя, потраченные на микроменеджмент и исправление последствий и принятие решений там, где это должен был сделать он. Я, как руководитель, хочу платить деньги профессионалу, а не маленькому ребенку.

2. На собеседовании нужно всегда задавать вопрос об ошибках. Простой вопрос «Расскажите о своей самой серьезной ошибке и что вы сделали, чтобы ее исправить?» мгновенно выявляет «Игорей». Они либо не могут вспомнить ни одной ошибки, либо рассказывают историю, где виноваты были обстоятельства или коллеги. Так не бывает в реальной жизни. Мы все ошибаемся и это нужно уметь признавать.

3. Нужно вовремя принимать решение об увольнении. Моя ошибка была в том, что я держал Игоря 5 лет в надежде, что он изменится. Люди меняются крайне редко. Моя задача как руководителя — не быть психотерапевтом, а собирать эффективную команду. Я затянул с этим решением, и это стоило компании и денег, и нервов.

Такие дела…

А у вас в практике был такой коллега — Игорь, который никогда не берет на себя ответственность и пытается ее спихнуть на другого человека?

Больше полезной информации про ИТ-управление, спорные вопросы в найме, менеджменте и планировании — в блоге Код ИТ-директора в Telegram, VK, Дзен, Instagram*, FB*. Подпишитесь, чтобы не пропустить новые тексты!

_{*Признаны экстремистскими организациями и запрещены на территории РФ.}