Размытое ТЗ на телефонию увеличивает итоговую смету на 30–50% за счет «дополнительных работ», которые подрядчик выставит после запуска. Чтобы избежать этого, требования должны быть описаны не функционально («нужна запись звонков»), а технически, с указанием конкретных параметров хранения и доступа к данным.
Архитектурные требования: облако против локального сервера
Первая точка конфликта — выбор между облачной и локальной архитектурой. Ошибка заказчика в том, что он доверяет выбор интегратору, который часто предлагает тот вариант, где выше маржа на лицензиях. Для компании до 50 рабочих мест облачная АТС экономит до 150 000 рублей на старте (отсутствие сервера), но локальная версия при штате 100+ сотрудников окупается за 1,5–2 года за счет отсутствия ежемесячной абонентской платы за каждого пользователя.
В ТЗ четко фиксируйте: тип развертывания, требования к серверному железу (если локально) и пропускную способность канала (минимум 100 Кбит/с на один одновременный разговор с запасом 20%). Экспертный вывод: выбирайте облачную АТС только если у вас распределенные офисы и нет штатного сисадмина; во всех остальных случаях для бизнеса от 50 человек локальный сервер надежнее и дешевле в долгосроке.
Интеграция с CRM: детализация API и событий
Фраза «интеграция с CRM» в ТЗ — это пустой звук, который ведет к доплатам за каждый новый сценарий. Требуйте прописать конкретные события: всплывающая карточка клиента при звонке (pop-up), автоматическое создание лида при пропущенном вызове, запись разговора в привязке к сделке. Например, при связке с Bitrix24 или amoCRM неправильная настройка вебхуков может привести к задержке появления карточки на 3–5 секунд, что критично для отдела продаж.
Обязательно укажите необходимость синхронизации истории звонков в обе стороны. Экспертный вывод: интеграция должна описываться через карту событий «действие — результат». Если подрядчик уклоняется от описания конкретных полей CRM, которые будут заполняться, он заложит эти работы в «допы».
Маршрутизация и логика распределения вызовов
Самая дорогая часть настройки — логика IVR (интерактивного голосового меню). Вместо «сделать меню» приложите к ТЗ схему переадресации. Пример: «Если звонок поступил с 09:00 до 18:00 → IVR → Отдел продаж (распределение по очереди) → если нет ответа за 15 секунд → переброс на руководителя». Без такой схемы внедрение затягивается на недели из-за бесконечных правок.
Укажите требования к очередям: линейное распределение, распределение по принципу «кто дольше не принимал звонок» или по компетенциям. Экспертный вывод: любой сценарий, не описанный в ТЗ, будет тарифицироваться как «изменение архитектуры». Рисуйте схему в Miro или Visio до подписания договора.
Требования к оборудованию и SLA по качеству связи
Не позволяйте подрядчику просто прислать список моделей IP-телефонов. Требуйте спецификацию по поддержке PoE (Power over Ethernet), чтобы не тянуть к каждому аппарату розетку 220В, что экономит до 20% бюджета на монтаж кабельной сети. Для удаленных сотрудников пропишите требования к софтфонам и совместимость с ОС (Windows/macOS/iOS/Android).
В части качества связи зафиксируйте недопустимые показатели: джиттер выше 30 мс, задержка (latency) более 150 мс и потеря пакетов > 1%. Превышение этих норм делает разговор прерывистым. Экспертный вывод: без жестких метрик качества в ТЗ вы получите систему, которая «работает», но по которой невозможно нормально общаться, а винить в этом будут вашего провайдера интернета.
Вывод
Чтобы внедрение IP-АТС не превратилось в бесконечный процесс с растущим чеком, начните с детального аудита текущих процессов и отрисовки карты звонков. Избегайте компаний, которые предлагают «типовые пакеты» без анализа ваших бизнес-процессов — это прямой путь к фатальным ошибкам при выборе компании по установке IP-АТС. Оптимальный выбор: интегратор, который фиксирует стоимость этапов в договоре и берет на себя ответственность за пропускную способность сети. Лучшая стратегия — максимально детализировать технические требования к API и SLA, чтобы перевести обсуждение из плоскости «нам кажется» в плоскость цифр и технических регламентов.