SLA на клиентский кабинет и корпоративный портал: что проверить в договоре

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

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

Соглашение начинается не с часов, а с классификации. Единое «время ответа на обращение» бесполезно: пока оно одно на всё, подрядчик держит быструю реакцию на просьбу поменять текст в шапке, а заказчик уверен, что по-настоящему срочное едет медленно.

Значение имеет не название класса, а то, кто его присваивает. Разумный порядок: класс ставит заявитель с вашей стороны, подрядчик понижает его только письменно и с объяснением, а на спорный случай есть эскалация — имя и телефон человека, которому звонят. Без этого классификация становится предметом переписки ровно тогда, когда переписываться некогда.

Часы ниже — картина по рынку для систем, от которых зависит операционная работа, а не наши договорные условия: собственные сроки мы собираем под проект и фиксируем в договоре, а не в блоге. Берите их как ориентир, с которым сверяют чужое предложение.

Три величины, которые в разговоре сливаются, а в договоре должны стоять отдельно. Реакция — момент, когда обращением занялся живой человек и вы об этом узнали. Восстановление работы — момент, когда операция снова проходит, пусть в обход: со вчерашним справочником, с ручной выгрузкой. Устранение причины может занять дни, и это нормально: сначала возвращают работу, потом ищут причину.

По этому месту подрядчика видно на переговорах: «устраним любую проблему за час» означает, что человек говорит о реакции и не замечает подмены. Спрашивать стоит про порядок — что происходит в первый час, когда вам дают промежуточный статус и кто решает включить обходной режим. И отдельно — с какого момента идёт отсчёт. Если канал один и письменный, отсчёт прозрачен; если «пишите в чат, а в срочном случае звоните», нет ни отсчёта, ни доказательства.

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

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

«Центр Сопровождения Бизнеса» занимается бухгалтерским учётом и сопровождением компаний разного профиля. Решив масштабироваться, собственник начал с клиентского сервиса, и мы разработали приложение: на первом экране — остатки по счетам, платежи текущие и запланированные, предстоящие задачи; вопрос к бухгалтерии решается во встроенном чате. На стороне компании — административный контур с чатами и уведомлениями.

Для разговора о поддержке важна одна особенность, и она читается прямо из состава экранов: сроки в этом продукте назначены не компанией и не клиентом, а налоговым календарём. В обычный вторник недоступность кабинета на три часа означает, что человек позвонит бухгалтеру, как звонил раньше. За два дня до сдачи декларации — очередь звонков и перенос платежей. Один и тот же простой стоит по-разному в зависимости от даты.

Вывод от себя: режим поддержки сервисной практики разумно привязывать к её календарю. Замеров доступности в кейсе ЦСБ нет, и выдумывать их мы не станем.

Медицинская группа EMC занимает ведущие позиции в России в диагностике и лечении онкологических заболеваний. Агенты из российских регионов и из-за рубежа обращаются к экспертам клиники за консультацией, и в кейсе сказано прямо: скорость и точность обработки заявок влияют на жизни пациентов. Раньше обмен шёл по разрозненным каналам. Сервис собран из двух модулей: агенту — форма с документами и видимым статусом, клинике — распределение задач по загруженности и экспертизе, уведомления о сроках, чат и права доступа.

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

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

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

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

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

Приложение ЦСБ раздаётся по закрытой ссылке в App Store и Google Play: подключениями клиентов управляет сам заказчик. У этой модели есть следствие, о котором вспоминают поздно. Серверную часть чинят и выкладывают за часы. Клиентскую — через публикацию сборки, и срок зависит уже не от подрядчика, а от проверки в магазине; до тех пор на телефоне остаётся сломанная версия, даже когда исправление готово. Поэтому для приложения «восстановление» описывают иначе: что чинится на сервере без выпуска сборки, есть ли переключатели, которыми ломающийся раздел отключают удалённо, и работает ли веб-вход как запасной путь. Сроки проверки в магазинах не называем: они меняются и зависят от состава изменений — это картина по рынку, а не наш замер.

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

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

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

Чего мы не обещаем: что сбоев не будет. Соглашение не делает систему безотказной — оно делает простой предсказуемым и проверяемым. Пока всё работает, записанный в договоре срок выглядит лишней строкой; цену ей назначает первый же отказ.

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

Иногда ответ звучит так: отдельный режим поддержки пока не нужен — нужен мониторинг и человек внутри компании, который принимает инциденты.