Для клиента срочный IT-запрос иногда выглядит как одно письмо. Для интегратора это может быть несколько часов инженерных проверок, переговоров с вендорами, пересчётов, поиска оборудования и десятки маленьких решений, о существовании которых заказчик никогда не узнает.
09:07
В почте появляется новое письмо.
Тема короткая:
URGENT RFQ
Внутри — спецификация.
Несколько позиций оборудования. Лицензии. Требования к гарантии. Срок поставки.
И последняя строка:
«Просим предоставить предложение сегодня до конца рабочего дня».
На первый взгляд всё просто.
Найти оборудование.
Получить цену.
Добавить сервис.
Отправить quotation.
Но именно в этот момент внутри СММХаб начинается работа, большую часть которой клиент никогда не увидит.
09:14 — Первое, что мы делаем, — не запрашиваем цену
Спецификация у технического специалиста.
И первый вопрос звучит не:
«Сколько это стоит?»
А:
«Это вообще правильно сконфигурировано?»
Проверяются модели.
Part numbers.
Совместимость компонентов.
Количество портов.
Память.
Диски.
Интерфейсы.
Подписки.
Support.
Warranty.
Сроки.
Иногда всё соответствует.
Иногда одна маленькая строка меняет весь проект.
Например, клиент запросил пятилетнюю поддержку, а выбранная позиция предлагается только с трёхлетней.
Или оборудование соответствует требованиям сегодня, но возможности дальнейшего расширения ограничены.
Или нужный компонент нельзя поставить в выбранную конфигурацию.
Или указанная лицензия покрывает не тот функционал.
Или решение технически работает — но существует более правильный способ решить ту же задачу.
Можно не заметить.
Запросить цену.
Отправить предложение.
Возможно, даже выиграть проект.
Но проблема проявится позже.
А «позже» в enterprise IT почти всегда стоит дороже, чем «сейчас».
09:38 — Коммерческий запрос ещё не ушёл, а первый вопрос уже отправлен вендору
Уточняем конфигурацию.
Параллельно account manager проверяет:
есть ли возможность зарегистрировать сделку;
кто отвечает за проект со стороны vendor;
через какого distributor можно получить предложение;
какие сроки производства;
есть ли оборудование на складе;
какие программы поддержки доступны;
есть ли специальные условия для проекта.
Со стороны клиента пока тишина.
Он отправил одно письмо.
Внутри СММХаб уже одновременно идут несколько процессов.
10:06 — Появляется первая цена
Это ещё не предложение клиенту.
Цена сама по себе мало что означает.
Нужно понять:
что именно в неё включено;
где находится оборудование;
какой lead time;
включён ли support;
какая warranty;
какая валюта;
сколько действует quotation;
какие условия оплаты;
какие логистические расходы появятся;
есть ли ограничения со стороны производителя.
Иногда две одинаковые модели оборудования на бумаге оказываются двумя совершенно разными коммерческими предложениями.
Одна доступна быстро, но с другой гарантией.
Вторая дешевле, но поставка займёт месяцы.
Третья выглядит дороже, зато включает поддержку, которую в первом варианте придётся покупать отдельно.
Поэтому мы не спрашиваем только:
«Какая цена?»
Мы спрашиваем:
«Что клиент реально получает за эту цену?»
10:41 — Инженер пишет: «Стоп»
Это одно из самых полезных слов в работе интегратора.
Обнаружена проблема.
Один компонент не соответствует другому.
На первый взгляд — мелочь.
Для клиента это одна строка Excel.
Для проекта — потенциальная задержка после поставки.
Теперь есть два варианта.
Первый:
ничего не менять.
Клиент именно это запросил.
Значит, можно просто дать цену.
Второй:
остановиться.
Перепроверить.
Предложить корректировку.
Мы выбираем второй.
Даже если это означает потерять ещё сорок минут в день, когда каждая минута уже имеет значение.
11:03 — Звонок
Vendor.
Distributor.
СММХаб.
Три стороны обсуждают одну маленькую часть спецификации.
Клиент этого разговора никогда не услышит.
И, возможно, это хороший признак.
Потому что если всё сделано правильно, большая часть проблем должна исчезнуть до того, как клиент узнает, что они могли существовать.
11:47 — Конфигурация меняется
Новый BOM.
Новая проверка.
Новый запрос цены.
Новый расчёт.
На часах почти полдень.
Предложения всё ещё нет.
Со стороны это может выглядеть так:
«Почему так долго? Там же несколько позиций».
Это справедливый вопрос.
Но есть большая разница между:
быстро отправить цену
и
быстро отправить правильное предложение.
Мы стараемся делать второе.
12:22 — Теперь появляется вопрос, которого не было в техническом задании
Срок поставки.
Нужная позиция есть.
Но не там, где хотелось бы.
Начинается следующий круг.
Есть ли stock у другого distributor?
Есть ли equivalent?
Можно ли ускорить delivery?
Есть ли альтернативная конфигурация?
Не изменит ли замена требования заказчика?
Сохранится ли vendor support?
Не повлияет ли другой SKU на гарантию?
Каждое решение тянет за собой следующее.
Именно поэтому в enterprise IT редко существует простое:
«Просто заменим эту модель на другую».
Иногда одна замена меняет половину архитектуры.
13:08 — Обед откладывается
Это не корпоративная легенда.
Так действительно бывает.
Потому что приходит сообщение:
«Price valid until today.»
Или:
«Stock: 2 units.»
Или:
«Please confirm immediately.»
В этот момент теория заканчивается.
Нужно принимать решение.
Но интегратор не может принимать его вместо клиента.
Поэтому задача СММХаб — быстро превратить техническую информацию в понятный выбор:
вариант A — быстрее;
вариант B — дешевле;
вариант C — лучше с точки зрения дальнейшего развития.
И объяснить разницу без двадцати страниц технической документации.
13:36 — Начинается работа, которую почти никогда не называют IT
Excel.
Курс валют.
Логистика.
Налоги.
Маржа.
Сервис.
Условия оплаты.
Стоимость поддержки.
Срок действия цены.
Коммерческие риски.
Enterprise IT существует не только в серверной.
Оно существует ещё и между строками коммерческого предложения.
Можно идеально подобрать оборудование и всё равно неправильно построить проект, если не учесть его экономику.
14:27 — Коммерческое предложение почти готово
Почти.
Но слово «почти» здесь важно.
Проверяем ещё раз.
Part numbers.
Количество.
Цены.
Warranty.
Support.
Services.
Delivery.
Payment terms.
Validity.
Потому что одна лишняя цифра в SKU может означать совершенно другой продукт.
Один неверный год support может изменить стоимость проекта.
Одна забытая лицензия может сделать оборудование функционально неполным.
Чем больше проект, тем дороже маленькая ошибка.
15:04 — Приходит новое письмо от клиента
«Просим также добавить инсталляцию, базовую настройку и обучение».
Хорошо.
Предложение снова открывается.
Теперь нужно понять объём работ.
Что именно подразумевается под installation?
Физический монтаж?
Initial configuration?
Integration?
Migration?
Testing?
Documentation?
Training?
Remote или on-site?
Сколько специалистов?
Сколько дней?
Иногда слово «настройка» занимает одну строку в запросе клиента.
Но за этой строкой может находиться совершенно разный объём инженерной ответственности.
Поэтому снова вопросы.
Снова расчёт.
Снова проверка.
15:52 — Всё готово
Можно отправлять.
Но перед кнопкой Send происходит последняя проверка.
Не потому, что мы любим усложнять процессы.
А потому что после этой кнопки документ перестаёт быть внутренним файлом.
Он становится обещанием компании клиенту.
Цена — обещание.
Срок — обещание.
Конфигурация — обещание.
Гарантия — обещание.
Услуга — обещание.
И если предложение подписано именем СММХаб, мы должны понимать, что именно пообещали.
16:07 — Send
Клиент получает письмо.
В нём PDF.
Несколько страниц.
Цена.
Срок.
Условия.
Описание.
Для клиента с момента его первого письма прошло семь часов.
Для СММХаб внутри этих семи часов произошло намного больше.
Проверка.
Vendor communication.
Distributor communication.
Технические вопросы.
Изменение конфигурации.
Stock check.
Новый BOM.
Пересчёт.
Логистика.
Support.
Сервис.
Финальная проверка.
И десятки сообщений, которые клиент никогда не увидит.
Так и должно быть.
Но история не заканчивается кнопкой Send
Через два дня приходит сообщение:
«Ваше предложение выбрано».
Для некоторых продавцов это финал.
Для интегратора — скорее начало второй половины работы.
Теперь цена превращается в обязательство.
Нужно подтвердить заказ.
Зафиксировать конфигурацию.
Проверить availability ещё раз.
Разместить PO.
Контролировать shipment.
Следить за документами.
Координировать доставку.
Организовать передачу оборудования.
Провести installation.
Настройку.
Training.
Закрыть документы.
А через несколько месяцев клиент может написать:
«У нас вопрос по оборудованию, которое вы поставляли».
И вот здесь становится понятно, была ли компания просто продавцом.
Или партнёром.
Почему мы рассказываем эту историю
Не для того, чтобы показать, насколько мы заняты.
И не для того, чтобы сделать обычный quotation чем-то героическим.
Это наша работа.
Но у IT-интеграции есть особенность:
клиент часто видит результат, но почти никогда не видит процесс, который сделал этот результат возможным.
Он видит сервер.
Не видит десятки проверенных конфигураций.
Видит firewall.
Не видит обсуждение лицензирования.
Видит storage.
Не видит вопрос совместимости, обнаруженный до заказа.
Видит коммерческое предложение.
Не видит двадцать сообщений между vendor, distributor, инженером и account manager.
И именно невидимая часть работы часто определяет, каким окажется проект через год.
Самая быстрая компания — не та, которая отвечает первой
В B2B существует огромное давление скорости.
И оно оправданно.
Клиенты не должны ждать неделями простой информации.
Но скорость сама по себе — плохой KPI, если она достигается ценой качества.
Можно отправить quotation за 20 минут.
А через три месяца обнаружить, что заказана неправильная лицензия.
Можно обещать короткий срок поставки.
А после подписания договора объяснять, почему оборудование задерживается.
Можно сказать клиенту «да» на каждый вопрос.
А потом выяснить, что технически нужно было сказать «нет».
Поэтому внутри СММХаб мы хотим измерять скорость немного иначе.
Не:
«Как быстро мы ответили?»
А:
«Как быстро мы смогли дать ответ, за который готовы отвечать потом?»
Для нас это гораздо более важная разница.
17:23
В почте появляется новое письмо.
Другой клиент.
Другая компания.
Другая задача.
Тема:
URGENT
Кто-то в офисе улыбается.
Открываем.
И всё начинается сначала.
СММХаб
Мы работаем с технологиями.
Но большая часть нашей работы на самом деле не про оборудование.
Она про решения.
Что выбрать.
Что проверить.
Где остановиться.
Где задать ещё один вопрос.
Где предупредить клиента.
Где не согласиться.
Где найти альтернативу.
И когда действительно нужно действовать быстро.
Потому что в IT слово «срочно» не должно означать:
«не проверять».
Оно должно означать:
«проверять быстрее».