Кейс Accelerist: Создание сайта по сбору средств

Заказчик
Заказчица - CEO проекта Accelerist Британи Хилл
Задача
Разработать новую версию сервиса, сделать качественный UI/UX дизайн и наладить работу user flow

Где деньги, Тим Кук? Как мы помогли НКО добраться до Google и Apple

В США зарегистрировано 1,5 млн благотворительных организаций, и каждая из них нуждается в финансовой поддержке. В 2020 году десять крупных компаний перечислили на счета НКО $2 млрд. Но не всем некоммерческим организация везет получить поддержку от Google или Apple — и они отправляются на поиски мецената.

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

Клиент нашего клиента

Мы всегда знали, что социальные связи важны, и кейс Accelerist это подтвердил. Заказчицу проекта, о котором пойдет речь, привели в Purrweb наши клиенты.

Рассказываем, как так вышло. В одном американском акселераторе Британи Хилл, CEO проекта Accelerist, пересеклась с ребятами из Wedy, для которых мы разработали сервис организации свадеб. Они рассказали Британи о своем опыте работы с IT-компанией из России, а затем связались с нами и предложили себя в качестве посредника в работе над Accelerist.

Так у проекта появилась команда разработки и два проектных менеджера. Я работала с внутренней командой, менеджер из Wedy поддерживал коммуникацию между нами и Британи. Все вопросы решали через менеджера Wedy. Мы сформировали команду из трех разработчиков, UI/UX дизайнера и QA тестировщика — и стартовали проект.

Фандрайзинг по-техасски

Фандрайзинг-сервис Accelerist — техасский стартап, цель которого помогать некоммерческим организациям получать деньги от коммерческих компаний. Через удобный поиск с фильтрацией НКО ищет спонсора, отправляет письмо на электронную почту и продолжает общение с представителем КО напрямую. В базе данных Accelerist сотни благотворителей, готовых пожертвовать деньги в любые отрасли — от помощи африканским племенам до спасения дельфинов в Тихом океане.

Как выглядит Accelerist

Accelerist существовал до нас, но работал нестабильно. Прошлые подрядчики написали некачественный код, а их пользовательский сценарий оказался неудобным для целевой аудитории — представителей НКО. Из-за того, что коммерческим компаниям приходилось регистрироваться на платформе, сервис не пользовался большой популярностью. Немногие организации захотят тратить время, а потом еще и деньги. Так что у НКО был не такой уж и большой выбор спонсоров.

Нам предстояло написать код, сделать качественный UI/UX дизайн и наладить работу юзер флоу.

Юзер флоу 2.0

Accelerist работает со спонсорами и благотворителями. В новом сценарии, который мы разработали для упрощения работы с платформой, коммерческим компаниям не нужно проходить авторизацию, как это было в старой версии. Информация о них берется из базы данных и выводится в виде карточек. Так мы получаем всех спонсоров, которые когда-либо занимались благотворительностью, а не только тех, кто захотел пройти регистрацию на Accelerist.

Мы разработали такой юзер флоу для некоммерческих организаций:

  1. НКО проходит регистрацию.
  2. Выбирает фильтры для поиска коммерческих организаций.
  3. Получает список компаний с основной информацией о спонсорах.
  4. Добавляет лучшие в «Избранное».
  5. Отправляет питч, собранный по темплейту, на электронную почту потенциального спонсора.

Что такое питч

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

Черновик для питча

В лучших традициях Dribbble

Заказчица предоставила низкодетализированные варфреймы. Валерий, UI/UX дизайнер в Purrweb проанализировал и придумал, как сделать из них high-fidelity версию. Британи Хилл прислала текстовые описание каждого раздела, а дизайнер проработал каждую страницу, разбил информацию на блоки, структурировал данные на основе принципов информационной архитектуры — в зависимости от приоритета для пользователя и паттернов взаимодействия с похожими сервисами.

У Accelerist были фирменные цвета: голубой и бордовый. От последнего мы ушли в сторону менее кричащего красного. Других референсов заказчица не дала, поэтому дизайнер отправился за вдохновением на Dribbble, Behance, Pinterest и Awwwards.

Там ничего лучше легкого, воздушного и минималистичного интерфейса пока не придумали. Мы не стали изобретать велосипед: под каждую страницу дизайнер подбирал несколько референсов и выделял лучшие практики. Было важно сделать так, чтобы UI дизайн помог пользователю решить задачу, не привлекая к себе лишнего внимания.

Дизайн для Accelerist сделали за месяц, не налажали с дедлайном. Пожалуй, это был самый «безболезненный» этап создания приложения.


Наверное, Accelerist — единственный мой проект, на котором было очень мало правок от клиента

Валерий Бойко, UI/UX дизайнер в Purrweb


У нас был план, и мы его придерживались

Для Accelerist выбрали стандартный стек технологий: Node.js на бэке и React на фронте. Мы не стремились использовать что-то модное — напротив, искали надежное решение, проверенное временем.

Наш план разработки выглядел так:

  1. Архитектура приложения.
  2. Авторизация для НКО.
  3. Сервисы Amazon S3 (облачные сервисы, которые позволяют хранить изображения, отправлять имейлы).
  4. Профайлы некоммерческих организаций.
  5. Страницы компаний-инвесторов.
  6. Авторизация администратора платформы.
  7. Избранное.
  8. Кастомизированные фильтры.
  9. Платежка и подписки.

Каждый этап — это новая фича в приложении. Некоторые процессы шли параллельно: например, один разработчик делал авторизацию в админке, другой — авторизацию для НКО. Мы всегда разделяем обязанности, потому что на проекте несколько разработчиков. Это помогает избежать споров и начать полноценное тестирование готовой части. Самым сложным и длительным этапом оказалось создание страниц компаний-спонсоров. Интеграция с ZoomInfo — отдельная история. Скоро расскажу ;)

Тиндер для НКО

Наташа, вставай, мы опять сделали Tinder. Да-да, мэтчим НКО и спонсоров…

Поиск с фильтрацией в Accelerist — фича, которой мы гордимся. На этапе регистрации некоммерческая организация выбирает несколько пунктов в Списке миссий и определяет цели в Области устойчивого развития. Например, миссии приюта для бездомных животных — Животные и приюты, а цель — Жизнь на земле. Если эти же параметры указаны в профиле коммерческой компании…

Бум! Итс э мэтч!

"Избранные" компании

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

Мэтчинг в Accelerist делался на основе уникальных формул — их предоставила заказчица. У Британи Хилл большой опыт в сфере благотворительности, она называет себя «лидером среди технологий для поиска спонсоров». Формулы для мэтчинга придумала она, а бэкэнд логику для них сделали мы — сейчас расскажу, как.

Мы получали данные о спонсорах из ZoomInfo, добавляли в нашу базу данных (PostgreSQL) и сравнивали с данными из профилей НКО. Если хотя бы один пункт совпадал, НКО мэтчилась с коммерческой компанией.

Совпасть могли CSR-фокус (цели долгосрочного развития), местоположение и еще несколько пунктов. Чем больше позиций замэтчилось, тем выше балл. Максимальный результат — 1235 поинтов.

Чем выше оценка, тем выше вероятность получить деньги от спонсора. Вот бы такую фичу добавили в Tinder :)

Три фичи, с которыми попрощались

Много хочешь — мало получишь. Зато все будет качественно и по делу.

Не все фичи из тех, что хочет заказчик, нужно реализовывать. Иногда важно объяснить, что некоторые функции не понадобятся конечному пользователю. Возможно, их сложно разработать, или они дорогие, или в мире еще не придумали технологию, чтобы реализовать какую-то хотелку.


Мы в Purrweb стараемся участвовать в создании продукта, а не просто реализовывать идеи заказчиков. И если что-то кажется нелогичным, мы не молчим, а идем на разговор, чтобы узнать, действительно ли те или иные функции нужны в приложении. Не всегда мы в итоге выпиливаем фичи, так как заказчик может иметь долгосрочный план, о котором мы не знали. Но в случае с Accelerist мы отказались от нескольких нелогичных хотелок и сэкономили бюджет

Сергей Никоненко, операционный директор в Purrweb


Расскажу побольше о фичах, которые могли быть в Accelerist, но их нет.

  1. Лайки ради лайков

    Заказчица хотела добавить фичу с лайками. Работали бы они как в условном инстаграме: каждый пользователь может поставить лайк любимой компании. Количество лайков отображалось бы в профиле организации. Но поскольку каждый спонсор жертвует деньги в определенной области, оценивать их лайками — нелогично. Решили убрать «лайки ради лайков» — вместо них есть список «Избранное», где лежат спонсоры, нужные конкретной НКО.

  2. Сложный поиск

    Мы реализовали поиск с фильтрацией, но заказчица попросила добавить систему ранжирования для каждого параметра. Например, фильтр «Пол» нужен НКО на 10 из 10, а фильтр «Производства» — на 5 из 10. Даже звучит запутанно. :D В итоге сама заказчица сказала, что это долго, дорого и не нужно.

    Ранжирование для сложного поиска

  3. Переход на старую платформу без авторизации

    У Accelerist уже была платформа, и нас попросили сделать так, чтобы некоторые ссылки с новой версии вели на старую. Заказчица хотела, чтобы пользователь, который залогинился в нашей системе, при переходе по ссылке автоматически авторизовался в старой. Но в чужую базу данных проход закрыт, поэтому мы даже в теории не могли сделать так, чтобы юзер «одним ударом» входил сразу в две системы. Так что мы сделали ссылки только на текстовые страницы, где регистрация не требуется.

Ручная работа: как интеграция с ZoomInfo сорвала нам все сроки


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

Мария Волкова, проектный менеджер в Purrweb


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

В Purrweb мы разрабатывали конкурента ZoomInfo с тем же набором функций. Мы предлагали заказчику использовать его — потому что в команде есть разработчики, которые создавали приложение, и знают его как свои пять пальцев. Но заказчица выбрала ZoomInfo — сервис, якобы, предложил специальные условия.

Желание клиента — закон. Но для нас это стало самой большой проблемой проекта.

План по работе с ZoomInfo был такой:

  1. Запрашиваем данные у Zoominfo.
  2. Они предоставляют API — точки доступа, через которые можно получить информацию и положить ее в нашу базу данных.
  3. Запускаем воркер получения данных о компаниях.
  4. Записываем эти данные в нашу базу данных PostgreSQL.
  5. Запускаем воркер получения данных о конкретной компании.
  6. Записываем эти данные в нашу базу данных.
  7. Запускаем воркер получения данных о возможных контактах, без получения имейла и телефона, просто получаем что email есть.
  8. Записываем новую информацию в нашу базу данных.
  9. Запускаем воркер получения данных о email контактов.
  10. Записываем в нашу базу данных.

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

  • Имя администратора компании-спонсора;
  • Название и контакты организации;
  • Местоположение спонсора;
  • Возможна ли связь через email;
  • Адрес электронной почты.

В процессе вскрылась еще одна проблема: названия в базе данных ZoomInfo не совпадали с реальными названиями компаний. Например, Amazon был записан как Amazon.com, а скрипт не понимал, что это одно и то же. Из-за путанницы с названиями многих компаний мы не смогли забрать данные через API — а это означало плюс время работы. Ведь если не работает API, данные приходят в виде Excel-документов, для каждого из которых нужен новый скрипт. Наши разработчики написали столько скриптов, что хватило бы на несколько проектов.

Данные о компаниях

А запросы, кстати, все еще платные.

Конечно, для Британи такой подход оказался слишком дорогим. Мы перестали запрашивать данные и решили искать альтернативный выход. Вместо бесконечных запросов заказчица купила у ZoomInfo полную базу данных. Вся информация была у нас в руках в виде Excel-документа. Но есть одно «но»: база данных ZoomInfo постоянно обновляется, и апдейты летят на интегрированные с ней платформы. А вот информацию в эксельке никто не апдейтит, поэтому данные о компаниях на Accelerist на первых порах обновляться не будут.

Однако, это решение заказчицы, принятое ради экономии бюджета.

Для эксельки от ZoomInfo написали скрипт, который парсит информацию из документа, поменяли типы полей в нашей БД, чтобы они соответствовали тому, что мы получили от сервиса.


Скрипт не сразу был идеальным. Когда он неверно считывал и забирал информацию, мы фиксили, тестили и правили. Фиксили, тестили и правили.

Дмитрий Крыхтин, тимлид в Purrweb


Куда летит информация о спонсорах

Основная задача Accelerist — упросить жизнь НКО, поэтому карточки компаний-спонсоров должны быть информативными. В каждой карточке есть три секции: Business Description Products, Social Impact и Customer Demographic. Расскажу, что включает в себя каждая секция и какие проблемы мы решили, чтобы их заполнить.

  • Business Product Description

    Здесь хранится основная информация: название, логотип, официальный годовой доход и контакты администраторов. Это и есть те данные, которые мы кровью и потом вытягивали из ZoomInfo. Они подгружаются автоматически из базы данных PostgreSQL, сформированной на основе той самой Excel таблицы.

  • Social Impact

    В этой секции лежат типы инвестиций, цели устойчивого развития согласно повестке ООН, сумма денег, которые может предоставить компания некоммерческой организации, ссылка на благотворительную программу. SI заполняется админом Accelerist вручную.

  • Customer Demographic

    В CD содержится информация об аудитории спонсора: пол, возраст, этническая принадлежность, политические взгляды и интересы. Данные для этой секции взяли из сервиса SpotRight — они тоже пришли в форме excel-документа. Документ на платформу загружает админ Accelerist, а мы отдаем нужную информацию на фронт в виде круговой диаграммы. Создать алгоритмы для этой задачи было несложно: все данные предоставил SpotRight, а мы прописали логику, по которой все и работает.

    Блок Business Description Products

Монетизировать благотворительность

У Accelerist одновременно простая и сложная система монетизации. С одной стороны, оплата идет напрямую, клиент и админ связываются по почте. С другой — есть тарифные планы, но как они работают, не поняли даже мы. :D Планы существуют, но о конечной стоимости пользователь все равно договаривается с админом.

Давайте разбираться вместе:

  • Кто платит? Who pays?

    Некоммерческие организации.

  • За что платит?

    Главные фичи — поиск с фильтрацией и карточки спонсоров Accelerist предоставляет только за деньги.

  • Как платит?

    Оплата происходит вне приложения. С платежной страницы юзера перебрасывает на почту, и он напрямую пишет администратору с вопросом о стоимости. Есть четыре тарифа с разным набором фич, но итоговая сумма оплаты все равно договорная. ¯\_(?)_/?

Так или иначе, Accelerist использует рабочую форму монетизации: будут деньги — будет доступ к фичам.

Отпустили в свободное плавание

Для Британи Хилл за пять месяцев мы сделали дизайн и разработку. Проект стартовал в сентябре 2020 и обошелся ей в $49,400. На этапе дизайна проблем не возникло, а вот разработчикам пришлось потрудиться — особенно под конец проекта.

База данных с информацией о пользователях, которую мы сделали на основе эксельки из ZoomInfo, обновляться пока не будет. И если какая-то компания обновит имейл, телефон или название, на платформе это не отобразится. Ответственность за обновление данных теперь лежит на администраторе платформы.

Какие выводы можно сделать из этой работы?

  1. Поддерживать связь с прошлыми клиентами — круто;
  2. Даже с проверенным сервисом может что-то пойти не так;
  3. Оценка проекта перед стартом работы важна, но обстоятельства могут сыграть против вас.
  4. Оставайтесь позитивными и работайте в команде — и все будет хорошо ;)

За месяц до окончания проекта Британи Хилл предупредила, что мы расстаемся. Мы подготовили UI kit, техническую документацию и передали проект ее внутренней команде. Accelerist уверенно стартовал с Purrweb в России, а теперь развивается где-то в Техасе. Я иногда поглядываю за ними в LinkedIn. Недавно узнала, что Accelerist занял 106 место в Inc. 5000 Regionals — списке быстрорастущих организаций Техаса. Гордимся нашим проектом. ^_^

Менеджмент Дизайн Разработка Контент
Мария Волкова Валерий Бойко Дмитрий Крыхтин Екатерина Кобзева
Никита Липник
Роман Васильев
Владислав Дюбов

Перейти на сайт

В карточку агентства

Письмо автору кейса

Пользуйтесь реальным опытом в IT и следите за успехами потенциальных подрядчиков и конкурентов
Подпишитесь на рассылку
Читайте также
Кейсы по теме#Государство и политика