Проект передан клиенту. Кто теперь продлевает сервисы и управляет доступами?
Я Алина, PR-менеджер Kartli. Ниже схема передачи цифрового проекта, в которой отдельно зафиксированы доступы, продления и дальнейшая поддержка. Это организационный шаблон, а не история конкретного клиента.
Передавайте перечень работающих сервисов
Начните с того, что понадобится после завершения основных работ. В перечне должны оказаться не все инструменты исполнителя, а сервисы, с которыми клиенту предстоит жить дальше: рабочее пространство с макетами, размещение приложения, база данных, интеграции.
Для каждого пункта укажите назначение, ссылку на кабинет и ответственного. Отдельно отметьте, что нужно только для просмотра готового результата, а что нужно для его изменения или работы самого продукта.
Такой список полезно пройти вместе на финальной встрече. Заказчик должен понимать, зачем существует каждая строка. Если объяснить её назначение трудно, это повод уточнить состав передаваемого проекта до завершения работ.
Разделяйте доступ и управление оплатой
Человек может видеть файл и при этом не управлять рабочим пространством. Поэтому проверка «ссылка открывается» закрывает только часть передачи. Отдельно выясните, кто может приглашать участников, изменять план и получать документы по оплате.
В Figma план и тип места определяют разные части доступа. Это хороший пример того, почему роли следует проверять внутри конкретного продукта. Для остальных сервисов состав прав уточняют в их собственных настройках и справке.
Передавать общий пароль всей команде для этой задачи не нужно. Используйте предусмотренные сервисом приглашения и передачу управления. Если выбранный вариант требует действий прежнего владельца, внесите их в список завершения проекта и проверьте результат вместе с получателем.
Назначайте дату смены ответственного
Фраза «дальше оплачивает клиент» оставляет несколько открытых вопросов. С какого дня меняется ответственность? Какой период уже покрыт? Кто проверит ближайшее продление? Что произойдёт с доступом исполнителя после передачи?
В условном акте передачи можно написать: «Заказчик принял управление рабочим пространством; ближайшее продление проверяет назначенный администратор; исполнитель сохраняет доступ только на согласованный период поддержки». Конкретные имена и даты стороны заполняют под свой процесс.
Полезно назначить и короткую контрольную проверку после передачи. Она покажет, что письма о продлении приходят нужному человеку, кабинет доступен, а ответственность не осталась только в итоговой переписке.
Отдельно передавайте работающие ресурсы
У готового приложения есть расходы, которые не связаны с тем, открыт ли редактор у разработчика. Например, в документации Replit отдельно описано использование ресурсов размещения и базы данных.
Для передачи это означает практический шаг: перечислите, что продолжает работать, где наблюдать использование и кто вправе менять настройки. Приложите краткое описание назначения ресурсов, чтобы будущий администратор не принимал решения по непонятным именам.
Остановку или удаление ресурсов согласовывайте отдельно с ответственным за продукт. В процессе передачи важно сохранить работоспособность и заранее определить, какие изменения допустимы. Сам список сервисов не является командой на отключение.
Проверяйте передачу действиями получателя
Попросите нового ответственного открыть кабинет, найти сведения о плане и показать, где лежит подтверждение оплаты. Если для этого по-прежнему требуется помощь бывшего владельца, отметьте оставшийся шаг, а не считайте передачу завершённой.
В результате у клиента должны быть понятные доступы, назначенные ответственные и ближайшая дата проверки. У исполнителя есть согласованная граница дальнейшей поддержки. Это делает завершение проекта управляемым для обеих сторон.
У Kartli есть инструкции по оплате зарубежных сервисов. При передаче проекта они дополняют описание конкретного кабинета: платёжный сценарий полезно хранить рядом с контактами человека, который будет им заниматься.
Алина, PR-менеджер Kartli · kartli.io