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

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

Кто такой методолог сегодня?

Это человек, который совмещает в себе: 📈 Проектировщика — чтобы видеть всю картину целиком; 🏗 Строителя — чтобы собирать процессы и знания в работающую конструкцию; 👷‍♂️ Инспектора — чтобы проверять, где возникают трещины и перекосы; 🤝 И немного управленца — чтобы договариваться между отделами и уровнями.

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

Реальный кейс из практики:

Крупный маркетплейс. Поддержка инхаус, одна линия, ≈ 200 человек. Всё работает, CSI выше 4,5. Принимают решение: передаём 1L на аутсорс в КЦ банка из топ-3. Экономия, масштабирование.

Через месяц CSI падает ниже 3,4. Клиенты жалуются. Операторы 1L постоянно эскалируют на инхаус-экспертов. Наши ребята захлебываются в эскалациях, SLA по сложным запросам выросло в 2 раза — поддержка просто не успевает.

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

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

Моё решение:

1. Перепроектировала архитектуру БЗ. Вместо «тем» — деревья решений. Вместо экспертного языка — язык клиента и оператора. Всё, что раньше было в головах у инхаус-экспертов, стало доступным алгоритмом.

2. Выстроила систему коммуникаций с кросс-командами. Договорилась с Product Owner, разработчиками, логистами и юридическим отделом о регулярных синхронизациях. Теперь они не «скидывают информацию когда есть время», а передают её в структурированном виде — изменения в продукте, новые сценарии, юридические нюансы. Я настроила процесс так, что актуальные знания поступают из первых уст, а не через третьи руки.

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

4. Настроила цикл обратной связи. Каждая эскалация — сигнал для улучшения. Мы с инхаус-командой анализируем новые кейсы и дорабатываем БЗ. За 2 месяца закрыли 80% повторяющихся проблем.

Что из этого вышло?

• Через 3 месяца CSI возвращается до 4,5.

• FCR растёт на 38%.

• Инхаус-эксперты решают свои задачам, а не разгребают эскалации.

• Кросс-команды (PO, разработка, логистика) теперь интегрированы в процесс обновления знаний — информация не задерживается и не искажается.

Мой инсайт:

База знаний — это не про «написать и забыть». Это про живую систему, которая питается от продукта и команд. Если нет каналов, по которым знания текут от PO и разработчиков к поддержке — БЗ умрёт. Моя роль как методолога — построить эти каналы. И именно helicopter view позволяет мне видеть, где эта связь рвётся, и чинить до того, как система рухнет.

P.S. Если ваш бизнес тоже столкнулся с тем, что аутсорс «не тянет» или знания уходят вместе с людьми — напишите мне. Расскажу, как мы это починили, и покажу, как можно у вас.

#методолог #архитектор #базазнаний #helicopterview #системныйподход #ecom #CSI #FCR #кейс #Сетка #клиентский_сервис