KZSalesHub | Все об ИТ-продажах

Jev — интересный пример того, как меняется подход к AI-архитектуре

Не каждая задача требует GPT, Claude или другой большой языковой модели.

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

Здесь и появляется интерес к Jev.

Для продавца это особенно интересно, потому что Jev можно рассматривать как отдельный слой между данными и большой LLM.

Например:

Лид пришёл → Jev определил его тип и приоритет → система выбрала сценарий → только после этого подключился AI-агент или LLM.

Или:

AI-агент собирается выполнить действие → Jev проверяет условия → если всё нормально, действие выполняется; если есть сомнения, подключается человек.

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

Я разобрал Jev именно с точки зрения продаж: что это такое, какие задачи можно решать, где его можно использовать вместе с LLM и как подобный подход может выглядеть в реальном IT-решении.

👉 Статья: https://kzsaleshub.com/sloj-reshenij-jev-dlya-prodavca/

Amazon Quick: 13 сценариев применения для разных подразделений

Как использовать Amazon Quick для решения практических задач бизнеса?

В статье разобраны 13 сценариев применения по ключевым направлениям:

• Финансы и управленческая отчетность
• Продажи и анализ коммерческих показателей
• Маркетинг и оценка эффективности кампаний
• HR и анализ кадровых данных
• Операционная деятельность и контроль показателей
• Подготовка отчетов и поддержка управленческих решений

Каждый сценарий - это конкретная задача, возможный подход к ее решению и ожидаемый бизнес-эффект.

📌 Полный разбор

Данные для продавца: что на самом деле стоит за «озером» и «хранилищем».

Data Lake, Data Warehouse, Lakehouse — термины знакомые, но на встречах с клиентом легко уйти в разговор про технологии и забыть про бизнес-задачу.

Для продавца важнее другое:

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

И главное — не продавать «соберём все ваши данные».

Лучше спросить: «Какой процесс сегодня принимается почти вслепую и какие цифры нужны, чтобы принимать решение?»

Разобрали Data Lake, Data Warehouse, Lakehouse, реальные точки затрат, красные флаги и вопросы от CTO.

https://kzsaleshub.com/dannye-dlya-prodavca/

3 ошибки при запуске нового отдела продаж

Мы часто видим одну и ту же картину.

1. Нанимаем продавцов без понятного процесса.
Продавец приходит и сам пытается понять, кому продавать, где искать клиентов и как вести сделку.

2. Ставим план «от желания».
Нужно 300 млн — ставим план 300 млн. Но если текущая воронка даёт 150 млн, план от этого не станет реальнее.

3. Неправильно настраиваем мотивацию.
Если система позволяет продавцу заработать больше, действуя невыгодно для компании, проблема в системе, а не в продавце.

Наш порядок:

сначала процесс → потом экономика → потом команда.

Разобрали подробнее в статье KZSalesHUB

https://kzsaleshub.com/tri-oshibki-novyh-otdelov-prodazh/

Amazon Quick — это уже не просто корпоративный AI-чат.

По сути, AWS двигает его в сторону AI-платформы для выполнения бизнес-процессов:

→ агенты выполняют многошаговые задачи
→ работают с корпоративными системами
→ могут создавать тикеты, обновлять сделки, отправлять письма
→ умеют работать через UI, даже если у системы нет API
→ подключаются к данным и внутренним системам через коннекторы и MCP
→ Research умеет проводить исследование по нескольким источникам и формировать результат с цитатами.

И здесь, на мой взгляд, самое интересное.

Amazon Quick стоит продавать не как «ИИ для сотрудников».

Правильнее смотреть на него как на платформу автоматизации конкретных бизнес-процессов.

И ещё один важный момент для бизнеса: экономика считается не только по количеству пользователей. В Quick есть такой ресурс, как agent hours — часы работы агентов.

Разобрали в статье, как устроен Amazon Quick, из каких компонентов состоит, чем отличается от Q Business и где здесь реальная ценность для бизнеса.

👉 https://kzsaleshub.com/amazon-quick-chto-eto-i-kak-ustroeno/

NRR — показатель, который показывает, растёт ли ваша клиентская база сама

В B2B часто смотрят на новые продажи и общий рост выручки. Но есть другой вопрос:

что происходит с теми клиентами, которые уже были у вас год назад?

NRR как раз это и показывает.

Если было 100 млн ₸ от существующей базы, а через год от этой же группы клиентов стало 115 млн ₸ — NRR = 115%.

Новые клиенты при этом не учитываются.

Почему это важно:

— ниже 100% — база сокращается, и новые продажи просто компенсируют потери
— 100–110% — база уже растёт сама
— выше 110% — сильная модель расширения

Но есть нюанс.

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

И ещё: NRR нельзя «нарисовать» просто повышением цены. Здоровое расширение обычно происходит за счёт большего использования продукта или сервиса: больше пользователей, объёма, подразделений, площадок.

В KZSalesHUB разобрали NRR подробнее — как считать, где он ломается и что с ним делать.

Читать разбор NRR →

BATNA и ZOPA: что нужно знать перед переговорами

Есть простая вещь, которую часто забывают перед переговорами.

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

Это и есть BATNA — лучший вариант, который у нас остаётся без этой сделки.

Например, клиент просит скидку 20%.

Если у продавца пустая воронка и сделка очень нужна — торговаться сложно.

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

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

И тут важно не торговаться только ценой.

Можно менять сроки, объём, оплату, поддержку, длительность контракта и другие условия.

Хорошая уступка — это не просто «хорошо, давайте дешевле».

Это:

«Можем дать скидку, если будет предоплата».

Или:

«Можем добавить этот объём, если увеличиваем срок договора».

В B2B-продажах это особенно важно.

Потому что переговоры — это не только про цену.

Разобрали BATNA и ZOPA в KZSalesHUB:

https://kzsaleshub.com/framework/batna-zopa/

Оборот растёт. Прибыль — нет.

Для проектной IT-компании это довольно частая история.

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

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

А надо смотреть на всю экономику сделки:

— сколько времени ушло на пресейл
— сколько часов реально потратила команда
— сколько стоили проигранные проекты
— сколько денег заморожено в отсрочке
— сколько съели поддержка и доработки

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

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

Разобрали на KZSalesHUB, как это считать.

👉 https://kzsaleshub.com/yunit-ekonomika-proektnoy-kompanii/

NDA: что продавцу нужно прочитать до подписи

NDA часто воспринимают как формальность: прислали документ — подписали — пошли дальше.

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

Я бы всегда смотрел минимум на четыре вещи:

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

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

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

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

И ещё несколько пунктов, которые легко пропустить:

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

Главное — не подписывать NDA прямо на встрече.

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

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

Читать статью на KZSalesHub

После внедрения проекта работа не заканчивается.

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

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

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

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

Время реакции — контролируете.
Время решения — далеко не всегда.

Разобрали всё на практике:

Поддержка после внедрения → KZSalesHUB

40 AI-инструментов для продаж

Сейчас уже сложно говорить просто про «AI в продажах».

AI постепенно появляется на каждом этапе процесса: от поиска и исследования лидов до звонков, встреч, CRM, аналитики и обучения команды.

Мы собрали 40 инструментов и разложили их по задачам:

🔸 исследование лидов — Clay, Ocean.io, 6sense, Common Room
🔸 CRM — folk, Attio, HubSpot, Day AI
🔸 холодный outreach — Jason AI, Unify, Persana AI, Octave
🔸 автоматизация — n8n, Make, Zapier, Bardeen
🔸 AI-агенты — ChatGPT, Claude, Perplexity и другие
🔸 контент — Lavender, Jasper, Coframe, Grammarly
🔸 аналитика сделок — Gong, Attention, Momentum, Rilla
🔸 холодные звонки — Air, Synthflow, OpenCall.ai, REGAL
🔸 встречи — Otter.ai, Avoma, Granola, Sembly
🔸 обучение и enablement — Navattic, Storylane, Arcade, Supademo

Но здесь есть важный момент.

Не нужно брать все 40.

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

Если менеджеры тратят часы на research — автоматизируем research.

Если теряются follow-up — автоматизируем этот процесс.

Если много времени уходит на подготовку к звонкам — смотрим в сторону AI-ассистента.

Если CRM превращается в ручную рутину — автоматизируем CRM-процессы.

То есть начинаем не с вопроса:

«Какой AI нам внедрить?»

А с вопроса:

«Где у нас сейчас самая дорогая ручная работа?»

Оттуда и выбираем инструмент.

Собрали всё на одной картинке, чтобы можно было сохранить себе.

Мы сделали новый бесплатный курс на KZSalesHUB — «ИИ в разработке продукта».

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

Но есть один нюанс.

Если просто дать разработчикам AI-инструменты, разработка от этого автоматически быстрее не станет.

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

Поэтому в курсе мы решили посмотреть на вопрос шире:

что вообще меняется в процессе разработки, когда ИИ становится частью команды?

Разбираем:

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

Без сложной теории и без «ИИ изменит всё».

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

Курс бесплатный, без регистрации.

9 модулей, около 50 минут:

https://kzsaleshub.com/courses/ai-pdlc/

Zero Trust. Что это вообще такое и зачем он нужен бизнесу?

Раньше безопасность во многих компаниях строилась достаточно просто.

Есть корпоративная сеть. Если человек внутри неё — ему доверяют.

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

Поэтому сама идея «мы внутри сети, значит всё безопасно» уже не работает.

Zero Trust предлагает другую модель:

не доверять автоматически никому.

Каждый запрос на доступ нужно проверить.

Кто пользователь?
С какого устройства он подключается?
К какому ресурсу хочет получить доступ?
Действительно ли ему это нужно?

И доступ даём не ко всей сети, а только к тому, что человеку или системе действительно необходимо.

Например, сотруднику бухгалтерии нужен доступ к финансовой системе.

Ему не обязательно видеть серверы разработки, CRM и внутренние базы компании.

Подрядчику нужен доступ к одному приложению на две недели?

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

В этом и есть одна из главных идей Zero Trust.

Но здесь есть важный момент.

Zero Trust — это не одна программа, которую установили и забыли.

Это целый подход, который затрагивает IAM, MFA, устройства, сеть, приложения, данные и процессы.

Поэтому внедрение обычно начинается не с покупки продукта.

Сначала нужно разобраться:

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

А уже потом выбирать технологии и строить архитектуру.

Мы разобрали Zero Trust подробнее в KZSalesHUB:

https://kzsaleshub.com/framework/zero-trust/

Если вы HR, руководитель команды или отвечаете за развитие сотрудников — вам знаком этот вопрос:

Кого повышать? Кого развивать? Кому давать больше ответственности?

И главное — кого готовить на руководящую роль?

Для этого есть простой инструмент — 9-Box Grid.

Он помогает посмотреть на сотрудников сразу с двух сторон:

— текущие результаты
— потенциал

В итоге получается матрица из 9 зон.

И здесь есть важный момент.

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

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

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

Поэтому 9-Box Grid — это не просто таблица с оценками сотрудников.

Это инструмент для HR и руководителей, чтобы понять:

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

Мы разобрали 9-Box Grid на KZSalesHUB и показали, что делать с каждой из девяти зон.

https://kzsaleshub.com/framework/9-box-grid/

DeepSeek только что выпустили кое-что интересное. И это не очередная модель.

Они открыли исходники DeepSeek Harness (dsh) — платформы для запуска и создания AI-агентов.

На первый взгляд кажется: ну ещё один framework для агентов.

Но внутри идея гораздо интереснее.

Главный принцип dsh — everything is a plugin.

Практически каждый компонент можно заменить или расширить: модель, инструменты, память, sandbox, storage, session и сам agent loop.

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

И здесь появляется Cordis — framework, который лежит в основе Harness.

У него довольно необычная архитектура с концепцией spatiotemporal composability. Если сильно упростить, речь о том, как компоненты системы могут взаимодействовать между собой не только структурно, но и с учётом состояния и событий во времени.

Для AI-агентов это довольно важная вещь.

Потому что современный агент — это уже давно не просто:

LLM → prompt → answer.

В реальной системе вокруг модели появляется целый слой:

модель + инструменты + память + контекст + состояние + выполнение действий + обработка ошибок + повторные циклы.

И вот этот слой постепенно становится отдельной технологией.

Мне кажется, здесь есть интересный тренд.

Раньше главный вопрос был:

«Какую модель вы используете?»

Теперь всё чаще будет:

«На чём работает ваш агент?»

Потому что две системы могут использовать одну и ту же модель, но давать совершенно разный результат из-за того, как устроены tools, memory, context, execution и agent loop.

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

И это, на мой взгляд, намного интереснее очередного релиза модели.

Похоже, мы постепенно переходим от Model Engineering к Agent Engineering.



GitHub: https://github.com/deepseek-ai/deepseek-harness

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

Маркетинг живёт в одной системе, продажи — в другой, Customer Success — в третьей.

У каждого свои KPI, свои отчёты и своё понимание воронки.

А потом руководитель получает три отчёта — и цифры не сходятся.

Именно из этой проблемы вырос RevOps — Revenue Operations.

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

И самое интересное — для небольшого бизнеса не обязательно сразу нанимать RevOps-директора.

Начать можно с четырёх вещей:

→ одного источника данных
→ единых определений
→ общей метрики
→ регулярной сверки всей воронки

Потому что RevOps — это не про CRM.

Это про переход от управления отделами к управлению потоком выручки.

Разобрали подробнее в новой статье KZSalesHUB:

RevOps: как из хаоса роста родилась отдельная профессия

Все мы слышали о чемпионах в разных книгах и методологиях продаж.

Но главный вопрос — как определить, что перед вами действительно champion?

Хороший контакт, заинтересованный собеседник или инициатор проекта — ещё не чемпион.

В enterprise-продажах я бы проверял три вещи:

1. Влияние
К его мнению прислушиваются там, где принимается решение?

2. Личный интерес
Есть ли у него причина продвигать изменения внутри компании?

3. Готовность действовать
Готов ли он сделать что-то, что требует от него определённых усилий и внутреннего влияния?

Последний пункт особенно важен.

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

И посмотрите, что произойдёт.

Потому что champion — это не человек, который говорит: «Мне нравится ваше решение».

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

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

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

https://kzsaleshub.com/framework/champion-building/

AI-агенту недостаточно дать доступ к корпоративным документам.

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

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

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

Поэтому между данными компании и AI-агентом появляется отдельный архитектурный слой — Enterprise Knowledge Layer.

Он должен понимать:

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

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

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

Только после этого имеет смысл подключать агентов.

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

→ [Enterprise Knowledge Layer: как превратить корпоративные данные в рабочую память AI-агентов](https://kzsaleshub.com/enterprise-knowledge-layer/)

ISO/IEC 42001: новый уровень AI Governance

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

Здесь стоит обратить внимание на ISO/IEC 42001:2023 — международный стандарт для системы менеджмента искусственного интеллекта (AI Management System, AIMS).

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

Важно: ISO/IEC 42001 — не стандарт на конкретную модель или технологический стек. Он про то, как компания управляет AI на уровне организации.

Для бизнеса это становится особенно актуально там, где AI уже влияет на клиентов, сотрудников, решения, данные и операционные процессы.

Поэтому компаниям, которые активно развивают AI, уже сейчас стоит смотреть не только на модели, RAG, агентов и инфраструктуру, но и на AI Governance, risk management, accountability и compliance.

Мы собрали практический разбор ISO/IEC 42001 и основных вопросов, которые стоит учитывать при построении AI-системы управления:

https://kzsaleshub.com/framework/iso-42001/

Если вы работаете с AI — этот стандарт точно стоит добавить в свой professional radar.

Интересно смотреть на этот проект не только как на строительство AI-инфраструктуры.

Если Казахстан и Армения действительно станут крупными точками AI compute, следующий вопрос — что будет построено поверх этой инфраструктуры.

Для Центральной Азии это может стать началом гораздо более интересного процесса.

Глобальные hyperscalers, AI-стартапы и новые технологические игроки получают возможность заходить в регион не просто с SaaS-продуктом, а с полноценной инфраструктурой для его развития и масштабирования.

А дальше возникает целая цепочка:

AI infrastructure → data → models → applications → integration → services → sales ecosystem.

И здесь появляется большое окно возможностей для локальных стартапов, интеграторов, cloud/AI-партнёров и новых игроков рынка.

Казахстан может стать одной из ключевых точек этой экосистемы, но потенциальный рынок значительно шире — Центральная Азия как единое пространство для разработки, локализации и продажи AI-решений.

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

Поэтому главный вопрос сейчас для рынка не «сколько будет GPU?».

А кто построит следующий слой бизнеса поверх этих GPU?

Видео с Дженсеном Хуангом