«Невидимые люди» — социальный проект для ситуаций, где помощь нужна, но её некому организовать рядом. Это могут быть люди без опекунов, без устойчивой поддержки семьи, без понятного маршрута к волонтёрам или НКО. В таких задачах цифровой продукт не должен превращать живую историю в холодную заявку, но и не может оставаться набором сообщений в чатах.
Pena работает с НКО и социальными проектами много лет, поэтому мы хорошо понимаем ключевое ограничение: благотворительная команда держится не только на доброй воле, но и на операционной дисциплине. Если обращение потерялось, статус не обновился, ответственный не назначен или чувствительные данные разошлись слишком широко, страдает не интерфейс — страдает человек, которому нужна помощь.
Задача
Проекту нужен был цифровой контур, который помогает собирать информацию о людях и ситуациях, требующих поддержки, а затем доводить эту информацию до действия. Не просто «оставьте заявку», а понятный процесс: кто сообщил о ситуации, что известно, какая помощь нужна, кто проверяет данные, кто отвечает за следующий шаг, что уже сделано и что остаётся открытым.
Для НКО это особенно важно. Команда может работать с волонтёрами, координаторами, партнёрами, местными сообществами и благополучателями. У каждого участника разный уровень доступа, разные задачи и разная ответственность. Поэтому продукт нужно проектировать вокруг процесса помощи, а не вокруг красивой формы.
Почему это сложнее обычной CRM
Типовая CRM обычно хранит лид, сделку, контакт и историю продаж. В проекте помощи основная сущность другая: жизненная ситуация человека. У неё есть контекст, срочность, риск, источник информации, уровень подтверждения, тип помощи, координатор, волонтёры, история действий и ограничения по приватности.
Если переложить такой процесс в обычную таблицу, быстро появляются типичные проблемы:
- обращения приходят из разных каналов и теряются между координаторами;
- данные о человеке смешиваются с комментариями, задачами и отчётностью;
- никто не понимает, какой статус у ситуации и кто отвечает за следующий шаг;
- чувствительная информация становится доступной шире, чем нужно для работы;
- повторная помощь не видна в истории, поэтому команда заново собирает контекст;
- отчётность для партнёров и внутренней команды собирается вручную.
Платформа должна была убрать эти разрывы и дать НКО единый рабочий контур.
Продуктовая модель
Мы рассматривали платформу как систему из нескольких связанных сущностей.
Карточка ситуации фиксирует, что произошло, кому нужна помощь, откуда пришла информация и какие данные уже подтверждены. Важно отделять факты от комментариев: координатор должен видеть не только текст обращения, но и степень уверенности в данных.
Карточка человека помогает не сводить историю к одной заявке. Если помощь повторяется, команда видит предыдущие действия, ограничения, предпочтительные способы связи и важные замечания.
Статусы показывают путь обращения: новое, на проверке, требуется уточнение, назначен ответственный, помощь запланирована, помощь оказана, требуется повторное действие, закрыто. Статус нужен не для отчёта ради отчёта, а чтобы команда не теряла управление.
Роли и доступы разделяют координаторов, волонтёров, администраторов и внешних участников. Не каждому нужно видеть все данные; часто достаточно задачи, адресного описания и инструкции, без лишнего контекста.
Журнал событий сохраняет историю изменений: кто добавил информацию, кто изменил статус, кто назначил волонтёра, какой комментарий оставил координатор. Для социальной помощи это критично: спустя время нужно понимать, почему было принято то или иное решение.
Экраны и визуальный контекст
Публичная часть проекта объясняет смысл простыми словами: «Невидимые люди» ищут тех, кому некому помочь, и организуют поддержку через волонтёров. Для таких проектов важна ясность: человек должен быстро понять, зачем существует инициатива, кому она помогает и как можно подключиться.
Инженерные решения
Главная инженерная задача в таких проектах — не усложнить интерфейс, но сохранить управляемость процесса. Волонтёрскому проекту не нужна перегруженная корпоративная система. Ему нужен понятный контур, который выдерживает реальные сценарии: неполные данные, уточнения, повторные обращения, разные уровни доступа и ручную координацию.
Модель данных без лишней бюрократии
Мы закладываем минимальный, но достаточный набор сущностей: человек, ситуация, обращение, тип помощи, ответственный, задача, событие, статус и вложения. Это позволяет развивать систему постепенно: сначала как рабочий MVP, затем как полноценную платформу для координации.
Приватность по умолчанию
В НКО-проектах нельзя проектировать доступ по принципу «все видят всё». Координатору может быть нужна полная история, волонтёру — только конкретная задача, администратору — отчётность и настройки, а публичному сайту — только обезличенная информация. Поэтому права доступа должны быть частью архитектуры с первого этапа.
Статусы как способ не потерять человека
Статусная модель помогает команде видеть, где требуется действие. Если обращение зависло на проверке, если помощь назначена, но не подтверждена, если требуется повторный контакт — система должна подсвечивать это. В социальном продукте статус — это не декоративный бейдж, а способ удерживать ответственность.
Отчётность без ручной сборки
НКО часто приходится объяснять партнёрам, что сделано, какие типы помощи оказаны и где остаются незакрытые потребности. Если события и статусы фиксируются в процессе работы, отчётность можно собирать из данных, а не из памяти координаторов.
Результат
Кейс «Невидимые люди» показывает подход Pena к социально значимым продуктам: мы проектируем не просто сайт, а операционную систему вокруг помощи. В ней публичная миссия связана с внутренним процессом, а человеческая задача поддержана понятными ролями, статусами, данными и ответственностью.
Для НКО такой подход даёт несколько практических преимуществ:
- обращения не распадаются между чатами, таблицами и личными сообщениями;
- координаторы видят текущие статусы и историю помощи;
- волонтёры получают понятные задачи и не перегружаются лишними данными;
- чувствительная информация распределяется по ролям;
- проект можно развивать по этапам, не переписывая основу;
- команда получает базу для отчётности, аналитики и масштабирования.
Где применим такой подход
Такая архитектура подходит не только проектам помощи одиноким людям. Её можно адаптировать для фондов, волонтёрских штабов, программ адресной поддержки, социальных служб, проектов помощи семьям, пациентским сообществам и локальным инициативам, где важно видеть не только обращение, но и весь маршрут помощи.
Pena полезна в таких задачах, когда нужно соединить эмпатию, продуктовую дисциплину и инженерную аккуратность. Мы не пытаемся заменить работу НКО технологией. Мы создаём инструмент, который помогает команде меньше терять информацию, быстрее назначать действия и бережнее работать с людьми.