Запуск сайта — важный момент, но не финал проекта. На следующий день появляются новые заявки, меняются даты, заканчиваются события, устаревают ссылки и накапливаются вопросы пользователей. Если заранее не определить, кто занимается этой работой, даже хорошо сделанный сайт постепенно превращается в архив старых анонсов.
Сопровождение не обязательно требует большой отдельной команды. Важно другое: регулярные задачи должны быть видимыми, права — распределенными, а сайт — принадлежать организации, а не отдельному сотруднику или подрядчику. Тогда площадка остается живой и управляемой.
10.1. Регулярные задачи
Работу с сайтом удобно разделить на редакционную, координационную и техническую. У этих направлений разные сроки и разные ответственные.
В «Щедром Екатеринбурге» заявки с сайта автоматически поступают во внутреннюю CRM фонда «Менора» — Битрикс24. Форма на сайте особенно важна для новых участников, которые нашли региональную акцию самостоятельно.
Форма заявки
Координатор ежедневно проверяет уведомления, связывается с заявителем, знакомится с организацией и событием, после чего отправляет шаблон карточки анонса. Если организация давно участвует в движении и уже знакома координатору, шаблон можно отправить напрямую.
Пример заполненного шаблона https://docs.google.com/document/d/14btaCoJwtOHiREXXQKPT1PgV7L43jK79j5h40oGrKjY/edit?usp=sharing
Предварительная проверка нужна не для формальности. Команда должна понять, соответствует ли предложение теме, ценностям и аудитории площадки. Например, заявитель предложил семинар по цифровым сервисам для школьных педагогов. После разговора выяснилось, что мероприятие не рассчитано на НКО и не соответствует аудитории регионального сайта, поэтому заявка была отозвана. Публикация события на сайте означает, что предложение прошло проверку команды, но при этом не должна подаваться как безусловная гарантия деятельности организатора.
После проведения акции начинается второй цикл работы. Организатор передает ссылку на итоговую публикацию, фотографии и результаты, а команда готовит новость для сайта. Желательно делать это в течение двух дней: своевременная публикация поддерживает открытость, сохраняет историю кампании и упрощает будущую отчетность. Интерес команды сайта к результатам также помогает выстраивать долгосрочные отношения с организаторами событий.
Координатор отвечает за первичный контакт, проверку заявителя и движение материала до публикации. Его стратегическая задача — следить, чтобы все согласованные события появились на сайте, а календарь был наполнен не только на ближайшие дни, но и по возможности на месяц вперед.
Редактор отвечает за текстовую и визуальную подачу. Он оформляет карточку события, добавляет сведения об организаторе и партнерах, следит за публикациями после мероприятия и при необходимости запрашивает подробности. На основе итогов редактор готовит новость для сайта, а перед активной неделей или днем — дайджест предстоящих событий и предлагает его партнерам, блогерам и СМИ. Такая коммуникация поддерживает не только информационный охват, но и долгосрочные отношения с организациями.
пример
Технические задачи выполняет отдел развития фонда и штатный IT-специалист. Он отвечает за безопасность, работоспособность сайта, обновления и критические настройки. Редакторы ведут содержание, а технический администратор контролирует состояние площадки и действия пользователей с расширенными правами.
Для небольшой команды подойдет простой ритм:
- постоянно — обрабатывать новые обращения и срочные изменения;
- еженедельно — проверять предстоящие события, формы и внешние ссылки;
- ежемесячно — просматривать каталог, главную страницу, статистику и завершившиеся события;
- перед крупной кампанией — обновлять медиа-кит, контакты, шаблоны и основные сценарии;
- ежегодно — проверять цели, структуру, юридические документы, безопасность, доступы и ответственных.
Это пример организации работы, а не обязательное расписание. Частота зависит от числа событий и возможностей команды.
10.2. Актуальность информации
Для посетителя старое событие без отметки о завершении выглядит как ошибка. Неработающая ссылка на регистрацию подрывает доверие сильнее, чем отсутствие дополнительной функции. Поэтому каждому типу материалов нужен понятный срок проверки.
Событие проверяют перед публикацией, незадолго до даты и после проведения. До начала важно подтвердить время, место, условия участия и ссылку. После — отметить завершение, перенести материал в архив или связать его с итоговой новостью. Если мероприятие отменено или перенесено, изменение должно быть видно сразу, а не только в социальной сети организатора.
Контакты и сведения об организациях можно проверять реже, например раз в несколько месяцев или перед новой кампанией. Медиа-кит обновляют перед активной работой со СМИ, статистику — после завершения отчетного периода, а юридические документы — при изменении процессов или требований законодательства.
У актуальности есть ответственный. Фраза «нужно иногда проверить» почти всегда приводит к тому, что проверка откладывается. Даже простая таблица с датой последнего обновления и именем сотрудника помогает увидеть, какие материалы требуют внимания.
Отдельная задача — внешние страницы. Региональный сайт направляет людей на формы регистрации и площадки организаторов, но не управляет ими. Поэтому перед публикацией и непосредственно перед событием полезно пройти путь пользователя: открывается ли ссылка, совпадают ли условия и понятно ли, что произойдет после заполнения формы.
10.3. Обучение команды
На сайте «Щедрого Екатеринбурга» редактор получает доступ к разделам, необходимым для повседневной работы, прежде всего к событиям и новостям. Максимальная рабочая роль для контент-команды — редактор. Она позволяет создавать и изменять материалы, но не открывает критические настройки сайта. Полные административные права остаются у технического специалиста, который отвечает за безопасность и работоспособность.
Такое разделение не мешает редактору вести сайт, но снижает риск случайно изменить технические параметры. Принцип прост: каждому человеку предоставляют не максимальные, а достаточные для его задач права.
В случае «Щедрого Екатеринбурга» административная часть сделана логичной и похожа на другие сайты фонда на WordPress, поэтому знакомым с этой системой сотрудникам легко в ней разобраться. У команды другого региона может быть Тильда, иной конструктор или собственная система управления. Название платформы здесь не главное: редактору должно быть удобно выполнять повседневные задачи, а обучение должно учитывать именно выбранный инструмент. При этом технический навык — только часть подготовки. Новости обычно проще оформить, чем анонсы, а короткие карточки событий требуют редакторского опыта. В нескольких фразах нужно передать суть, заинтересовать человека и дать честный призыв к действию.
Даже после заполнения шаблона организации могут прислать сухой или перегруженный текст. Его нужно привести к общему стилю, не исказив смысл и не пообещав лишнего. Если есть возможность, к этой работе полезно привлечь маркетолога или редактора на условиях pro bono. Он поможет с короткими формулировками и призывами к действию. По опыту команды«Щедрого Екатеринбурга» , после одной кампании редактор уже значительно увереннее справляется с такими материалами самостоятельно.
Сейчас отдельного руководства по работе с сайтом нет: постоянная команда знакома с WordPress и похожими административными панелями. Это особенность данного проекта, а не универсальное условие. Независимо от выбранной платформы короткая инструкция сделает накопленный опыт доступным новым редакторам. В нее достаточно включить:
- порядок создания и проверки карточки события;
- публикацию новости;
- правила работы с изображениями и ссылками;
- редакционный стиль;
- границы прав редактора;
- порядок сообщения о технической проблеме;
- контакты ответственных.
Такой документ не обязан быть большим. Несколько пошаговых сценариев с примерами полезнее длинного описания каждой кнопки административной панели.
10.4. Передача проекта
Устойчивость начинается с права собственности. Сайт «Щедрого Екатеринбурга», домен и хостинг принадлежат региональному оператору акции — благотворительному фонду «Менора». Битрикс24 также является внутренней системой фонда: сайт использует ее для заявок, но другим региональным командам не обязательно выбирать ту же CRM.
Техническую поддержку обеспечивает отдел развития фонда, а разработчик фактически является штатным сотрудником. Благодаря этому проект не зависит от личного аккаунта внешнего исполнителя. С момента запуска состав ответственной команды сохраняется. Постоянство сотрудников помогает удерживать знания, договоренности и единый подход к работе с сайтом.
Кадровая стабильность не отменяет необходимости хранить основные сведения на уровне организации. У ответственных должны быть:
- доступы к сайту, домену, хостингу, почте, аналитике и CRM;
- контакты технических специалистов;
- сведения о лицензиях и подключенных сервисах;
- краткое описание ролей;
- порядок резервного копирования и восстановления;
- редакционные правила.
Резервные копии проекта хранятся в нескольких местах: на VPS, отдельно в облаке, а также в виде снимков и резервных копий на стороне хостинга VPS. Такое разделение снижает риск потерять одновременно и основной сайт, и единственную копию.
Передавать проект новым сотрудникам пока не требовалось. Это связано со стабильностью команды, а не со случайной текучестью кадров. При необходимости понятная административная часть и краткое руководство позволят быстро ввести нового редактора в работу. Хорошая передача проекта — не ожидание ухода человека, а способ закрепить знания организации.
10.5. План развития
После запуска почти неизбежно появляется длинный список идей. В нем могут быть полезные улучшения, привлекательные эксперименты и функции, которые потребуют больше ресурсов, чем принесут пользы. Поэтому список пожеланий еще не является планом развития. Сначала идеи нужно сгруппировать, проверить и расставить по приоритету.
На 2027 год команда выделила три приоритетных направления.
Первое — цифровые форматы помощи и тематические акции. На сайте нужен раздел, который простым языком объясняет, как работают краудфандинговые платформы, какие форматы помощи существуют и почему проверенным цифровым инструментам можно доверять. В качестве пилота можно запускать тематические подборки или акции, предлагающие в определенную дату поддержать несколько проверенных организаций. Перед запуском необходимо определить правила отбора, проверить актуальность сборов и честно объяснить, кто получает помощь.
Второе — аналитика и путь посетителя. Команда хочет связать разные действия: просмотр страницы, лайк, переход к регистрации, подтвержденную регистрацию и пожертвование. Сейчас лайки учитываются обезличенно, а запись на события проходит на стороне организаторов, поэтому единой ежедневной сводки регистраций и пожертвований нет. Сквозная аналитика потребует новых интеграций, договоренностей с внешними площадками и оценки правил работы с персональными данными. До этого момента разные действия нужно показывать раздельно и не выдавать переход за завершенную регистрацию.
Третье — поиск и рекомендации. Пользователю можно помогать находить события по организации, аудитории, теме или формату помощи и предлагать похожие инициативы. Начинать нужно не с «умного» алгоритма, а с качественных меток и структуры данных. Прежде чем выбирать фильтры и правила рекомендаций, команда проанализирует данные 2026 года.
Развитие «Банка идей», уведомления, игровые механики и голосования остаются в перечне гипотез. Каждую такую функцию нужно проверять на соответствие ценностям движения и ресурсам команды. Голосование не должно превращать социальные инициативы в несправедливое соревнование, а уведомления требуют ясного согласия и умеренной частоты.
Сбор пожертвований непосредственно на региональном сайте — отдельный большой проект, а не еще одна кнопка. Он затрагивает юридическую ответственность, выбор получателей, платежную инфраструктуру, безопасность, отчетность и доверие. Прежде чем добавлять такую функцию, стоит проверить, нельзя ли решить задачу понятными переходами на уже работающие и проверенные площадки.
10.6. Принцип устойчивого развития
Устойчивый сайт развивается не по количеству добавленных функций, а по способности команды поддерживать их после запуска. Каждый новый фильтр требует актуальных данных, уведомления — контента и контроля частоты, карта — достаточного числа проверенных адресов, а интеграция — наблюдения и технической поддержки.
Перед каждой доработкой полезно ответить на четыре вопроса:
- Какую подтвержденную проблему она решает?
- Для какой аудитории она предназначена?
- Кто будет отвечать за ее содержание и работу?
- Как команда поймет, что решение оказалось полезным?
Если ответов пока нет, идею можно оставить в списке гипотез. Это не отказ от развития, а защита проекта от функций, которые красиво выглядят на презентации, но быстро перестают обновляться.
Опыт «Щедрого Екатеринбурга» показывает два вида устойчивости. Техническую поддерживают принадлежность сайта региональному оператору, разделение прав, штатный специалист и резервные копии в нескольких местах. Редакционную — постоянная команда, живые отношения с организаторами, проверка заявок и регулярная публикация результатов.
Региональный сайт «Щедрого вторника» не должен быть однажды завершенным цифровым продуктом. Он меняется вместе с сообществом, но остается понятным, безопасным и посильным для своей команды. Именно такой подход позволяет начать с рабочей версии, учиться на реальных сценариях и постепенно превращать сайт в устойчивую площадку для добрых дел в регионе.
Отдельный вопрос устойчивого развития — разумное использование искусственного интеллекта. Следующая глава показывает, где он может сэкономить время небольшой команды, а где без проверки человека и установленных правил не обойтись.