Опыт создания CRM-системы для управляющих компаний

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

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

Разработкой я начал заниматься еще в 2015, параллельно основной работе. Сначала был стартап, потом фриланс, и вот - свой проект, идея которого возникла в результате череды событий.

Меня раздражало мобильное приложение нашей управляющей компании (далее - УК). Никакой интерфейс, но больше всего я недоумевал над мелкими ошибками, которые затрудняли использование в принципе, но которые было возможно починить элементарно на мой взгляд. Дело в том, что на экране передачи показаний счётчиков, если ввести показания одного и перейти к полю следующего счетчика и ввести показания, то в предыдущем счетчике показания тоже менялись. Я пробовал связаться с разработчиком, предложить помощь, сотрудничество, но мне дали понять что сами справятся.

Был еще один момент. В то время мы оказывали услуги по разработке документов для одной местной УК. В ходе работы выяснилось, что они используют систему диспетчеризации (+ мобильные приложения) того же разработчика что и УК управляющая мои домом. И они постоянно получали жалобы на работу именно мобильных приложений клиентов.

И тогда я решил что смогу сделать свое решение. Мне хотелось создать что-то лучше, чем то что было, что-то качественнее. Так родилась идея своей системы диспетчеризации.

Честно сказать, я не думаю что провел исчерпывающее исследование. Моей целью был наш локальный рынок в регионе (для начала хотя бы). На тот момент я толком не понимал даже целевую аудиторию которой было бы интересно мое решение. Сейчас я обозначил бы её как “небольшая УК, в которой максимум работы ведется на бумаге, не автоматизированы процессы и нет своего приложения для клиентов”.

Я дважды заказывал отчет в сервисе Яндекс.Взгляд, чтобы хоть примерно оценить спрос на такой продукт как система диспетчеризации или, как я считал на тот момент - CRM система для УК. И вот какие результаты я получил (на фото ниже):

Дальше я прикинул сколько есть УК в регионе, посчитал финансовую модель на полтора года вперед, примерные точки роста и окупаемости и постарался учесть все расходы. Исходя из расчета, я получил те параметры, при которых примерно через год проект должен был выйти в плюс. Но тем не менее пока остается вопрос реализуемости этих параметров.

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

Практически все решения которые я нашел в интернете предлагали схему монетизации, когда есть какая-то плата за количество лицевых счетов. Поэтому я не стал изобретать велосипед и взял этот вариант за основу.

С 2015 я занимался нативной разработкой на Swift под iOS. И исходя из прошлого опыта стартапа, не хотел на старте зависеть от разработчиков Android, бэкендеров, а также маркетологов с дизайнерами.

Для начала надо было определиться с платформой для фронта. Посмотрев варианты мне приглянулся Flutter и я решил выбрать эту платформу. До того момента я ни разу не сталкивался ни с Flutter, ни с языком Dart, однако втянулся очень быстро. Уже в первый вечер была болванка пустого приложения для iOS и Android, пустая, но с рабочим интерфейсом.

Следующим нужно было решить вопрос бэкенда. И, так как у меня уже был опыт работы с Firebase, я решил выбрать его. В нем есть все что нужно: база, пуш-уведомления, метрики, хостинг… В общем всё что надо.

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

Следующим этапом я разработал мобильные приложения для клиентов. Оно состоит из 4 разделов: сообщения, заявки, счетчики и профиль. В будущем планирую добавить возможность оплаты услуг УК из приложения, но есть некоторые вопросы, которые нужно решить перед внедрением.

И вот, спустя полгода MVP был готов.

Мне повезло, один из моих знакомых был директором небольшой управляющей компании. Я поговорил с ними и их заинтересовало мое решение, мы договорились о встрече.

В ходе беседы выяснилось, что у них все процессы построены на бумаге. Было разве что пара таблиц Excel и всё. Им хотелось навести порядок в этом хаосе автоматизировать работу. Тогда мы решили доработать мое решение под их нужды.

Одним из основных требований была разработка мобильного приложения для сотрудников с разными ролями (директор, мастер и исполнитель).

То как сейчас выглядит приложение для исполнителей видно на скриншотах:

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

В последствии, перед тем как начать получать заявки, пришлось перенести базу с Firebase из-за федерального закона “О персональных данных” № 152-ФЗ. Но к тому моменту разбираться с бэкендом уже не было времени, поэтому я пригласил в проект знакомого бэкендщика. Я арендовал VDS, а он развернул на нем базу. Переписали приложения и всё заработало.

Спустя чуть больше чем полтора года, мы имеем систему диспетчеризации с неплохим функционалом:

Но пока разработка ведется только для одного клиента.

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

Пока проект окупает только собственные ресурсы в плане хостинга и аренды VDS, но и это я считаю не плохо.

Спасибо за внимание!