// личный кабинет клиента по тендеру

Техническое задание на личный кабинет клиента: что обычно пропускают в тендерной документации

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

Проблема в том, что кабинет сам по себе почти ничего не хранит. Это витрина над учётными системами заказчика, и от того, как она к ним подключена, зависит, увидит ли клиент актуальный счёт или вчерашний. Если в ТЗ этого нет, каждый подрядчик понимает задачу по-своему. Заявки получаются несравнимыми, а цена и сроки оценены под разные системы.

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

Что обычно упускают в ТЗ

Не указано, откуда кабинет берёт данные и как часто они обновляются

Чем оборачивается. Подрядчик закладывает один способ получения данных, заказчик ожидает другой. Выясняется это уже в разработке: нужна интеграция, которую никто не оценивал. Клиент при этом видит устаревшие счета и статусы заявок и всё равно звонит оператору, то есть кабинет не решает своей задачи.

Как написать правильно. Добавьте в ТЗ раздел об источниках данных. Для каждого типа информации (договоры, счета, заявки, обращения) укажите исходную систему, способ передачи и допустимую задержку обновления. Отдельно опишите, что показывает кабинет, если источник временно недоступен.

Регистрация и восстановление доступа не описаны

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

Как написать правильно. Опишите сценарии отдельно: первичная регистрация и подтверждение личности клиента, привязка к договору, смена и восстановление пароля, поведение при утере доступа к телефону или почте. Для юридических лиц отдельно укажите, кто и как получает доступ от имени организации.

Нет требований к защите входа

Чем оборачивается. В кабинете лежат договоры и финансовые данные клиентов. Формулировка вроде «система должна быть безопасной» не проверяется, а значит, её нельзя ни принять, ни оспорить. Подрядчики закладывают разный уровень защиты, и заявки перестают быть сопоставимыми. Последствия слабой защиты доходят до заказчика уже после запуска.

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

Не расписано, что клиент меняет сам, а что только через оператора

Чем оборачивается. Без разделения прав каждый понимает «личный кабинет» по-своему. Одни ждут, что клиент сам подаёт заявки и правит контактные данные, другие считают, что кабинет только для чтения. Расхождение всплывает на приёмке, и закрывается оно доработкой за отдельные деньги или спором о том, что входило в задачу.

Как написать правильно. Сделайте таблицу прав: по каждому объекту (контактные данные, заявки, обращения, документы) укажите, что клиент может создавать, редактировать, только просматривать и что возможно лишь через оператора. Добавьте описание ролей оператора и порядка подтверждения изменений.

Отчёты для руководства забыты

Чем оборачивается. ТЗ целиком написано с позиции клиента, а у заказчика есть собственные вопросы: сколько клиентов пользуются кабинетом, какие обращения самые частые, где копятся заявки. Если отчётов в документе нет, их приходится заказывать отдельно после запуска. Руководство при этом не видит, окупается ли система и пользуются ли ею.

Как написать правильно. Выделите в ТЗ раздел аналитики и отчётности. Перечислите, какие показатели нужны руководству, в каком виде и с какой периодичностью, кто имеет к ним доступ и можно ли выгружать данные. Даже краткий перечень показателей лучше, чем его отсутствие.

Приёмка не привязана к сценариям использования

Чем оборачивается. Когда критерии приёмки сформулированы общими словами («кабинет работает корректно»), любая сторона может трактовать их в свою пользу. Результат: затянутая приёмка, возвраты на доработку и взаимное недовольство, хотя формально работа выполнена.

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

Что даёт хорошее ТЗ

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

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

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

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

Сколько стоит и сколько занимает

Техническое задание — от $400, 1–4 недели: цена зависит от сложности системы, архитектуры, стека и интеграций. Разработка на субподряде — по объёму контракта, оценка до подачи заявки.

ТЗ для тендера или субподряд — подробнее →

Заказчиков и закупки не называем: разбираем типовое ТЗ, а не чей-то тендер.

Готовите закупку или уже выиграли тендер?

Обсудить тендер