Компания подключает интернет в ресторанах, офисах, магазинах, салонах красоты. У провайдера получается много крупных клиентов, у каждого из которых есть разные объекты в черте города.
Типовой пример: есть головная организация, которая занимается финансированием всех своих филиалов — маникюрных салонов. Таких салонов в каждом районе города может быть несколько, у каждого своё отдельное начальство, с кем нужно составить договор, но у всех них есть один общий начальник — он и отвечает за оплату.
Получается, что в карточке клиента нужно учесть не только всю информацию по конкретной точке подключения, а ещё связать её с другой организацией. Ещё нужно в этой же карточке видеть отдельный баланс на точке и общий баланс по головной организации в целом. Ещё одни клиенты платят раз в месяц, а другие — раз в квартал. А третьи вообще работают по бартеру и в их карточке нужно отразить стоимость всех работ, которые пойдут в зачёт.
Все коробочные решения на этом месте дают сбой и требуют плотной работы программистов. И не факт, что всё получится сделать как нужно — у каждой коробочной архитектуры есть свои ограничения, которые нельзя обойти.
У провайдера учёт всех клиентов и объектов был в гугл-таблицах. Из-за этого бухгатлерам и менеджерам приходилось еженедельно тратить много времени на контроль оплат по объектам клиентов и расчет дебиторки. Что-то считалось в таблице само, остальное делали вручную и записывали в отдельный файл. Забыли записать данные → бухгалтерия не видит задолженности → никто не напоминает об оплате → компания работает в минус.
Ещё пара неудобств:
Таблицы Google — отличный выбор для начала работы. Там рождается структура данных. Именно там становится понятно, какие поля реально нужны и используются менеджером, а какие надуманы и не нужны в системе. Но со временем данных становится все больше и таблицы больше не справляются.
Коробочное решение не подходит таким клиентам из-за своей жёсткой структуры. Поменять что-то внутри очень сложно, а если для каждой головной организации нужно делать отдельное представление для карточки, это ещё и дорого.
Можно было написать систему самостоятельно. На это ушло бы больше денег, чем на разработку с помощью low-code платформы: пришлось бы писать свой бэк, фронт, а потом заставить обе системы работать вместе. Плюс — не забыть заложить бюджет на поддержку написанной системы. Но если уже есть укомплектованный отдел разработки, задача не срочная и есть деньги — это тоже вариант.
Главный итоговый пользователь этой системы — не менеджеры и бухгалтеры, а босс-руководитель, которому важно видеть значения ключевых парамеров:
Использовать для этого гугл-таблицы неудобно — всех готовых ячеек с такими показателями там нет, нужно брать цифры из других файлов.
Чтобы решить эту проблему, мы написали простого телеграм-бота (за 3 часа), который каждый день в 10 утра заходит в базу, берет небольшую сводку за вчерашний день, все ключевые параметры по бизнесу и отправляет отчет руководителю.
С ботом пришлось пошаманить, чтобы он не падал, если база вдруг не отвечает и верно обрабатывал остальные ошибки (ещё 2 часа работы). На рассылку подписали и босса клиента и его технического директора на всякий случай.
Теперь каждый день руководитель и техдир получают от бота автоматическое сообщение с ключевыми показателями бизнеса. В конце сообщения всегда стоит ссылка — можно по ней перейти и посмотреть детальный отчёт:
Раньше все менеджеры каждый день загружали и смотрели выписки из банка, а потом руками заполняли в таблице, какой из клиентов сколько денег перевел за какой объект. Бухгалтерия смотрела на это и грустно вздыхала.
На старте проекта в ozma.io ещё не было интеграции с банками, поэтому решили так:
Кроме этого, на старте мы вместе решили отказаться от учета транзакций по объектам и оставить аналитику только по клиентам. Провайдеру неважно, за какой именно объект клиент недоплатил — ему важно, чтобы в целом за все свои объекты каждый клиент платил вовремя.
Разные банки в транзакциях могут выдавать разные данные. Кто-то указывает номер счета, кто-то ИНН получателя, а кто-то — и то, и другое и ещё служебный номер перевода. Ещё есть проблема с разными форматами — их все нужно тоже привести к одному виду.
Чтобы все работало без проблем, мы разработали процедуру привязки транзакции к контрагенту. Если нам пришла транзакция с номером счета, который уже есть в базе и привязан к нужному контрагенту, то всё просто — связываем их друг с другом.
Сложный случай — данных нет, надо угадать контрагента по названию. Важно не учитывать при сравнении небольшую разницу вроде кавычек или больших букв. И уже после этого можно создавать между ним и транзакцией счет, завести ИНН и заполнить все остальные поля в карточке контрагента.
Раньше в гугл-таблице эти данные были в одну строку и работать с ними было неудобно. Переделали, запрограммировали, добавили нужные поля — стало нагляднее:
Раньше информация по клиенту дублировалась в каждом объекте в google таблицах. Теперь появился список клиентов:
В этом списке сразу видно какой из клиентов сколько заплатил по месяцам, а также сколько в итоге клиент нам остался должен или переплатил. Все считается автоматически. Если нажать на любую строку, откроется карточка клиента:
Даже на маленьких экранах смартфонов вёрстка не плывёт, данные не залезают друг на друга, а все подписи остаются читаемыми. При этом система полностью рабочая, как на компьютере — можно работать с любыми данными и они автоматически сохранятся на сервере.
Для тех, кто искал в статье технические подробности работы и не нашёл их, мы написали отдельную статью — там много кода, SQL, JavaScript и примеров того, как это работает.
Хочется автоматически тянуть транзакции из банка. Сделать так, чтобы пользователю не приходилось подгружать выписки руками. Планируем сделать в следующей итерации.
Добавить еще ключевых показателей: остаток на счету, фактический доход и прибыль.
Отобразить ключевые показатели в динамике. Скоро на ozma.io появится отображение графиков, и тогда дашборд для руководителя станет еще веселее )
Дать возможность менеджерам по продажам работать со сделками на ранних стадиях. Для этого в систему можно добавить канбан-доску со статусами продажи, чтобы менеджер мог двигать сделки по нужным стадиям.
Так как система разработана на low-code платформе ozma.io, эти улучшения может делать интегратор или сам клиент, если у него есть свои разработчики.
Я Кирилл Маркин, основатель компании Ozma Inc. Сейчас занимаюсь развитием и обучением интеграторов платформы ozma.io: мы помогаем разработчикам собирать для своих клиентов красивые CRM и ERP системы. Моя цель — чтобы любой разработчик мог собрать решение для клиента за несколько дней.
Если вы хотите научиться делать такое же для своих клиентов или для себя — напишите, обсудим детали.
Если вы хотите попробовать собрать что-то в ozma.io для себя или для своих клиентов, или хотите просто посмотреть, как в ней работать — зарегистрируйтесь и мы пришлём вам на почту ссылку на личный кабинет. Функционал в личном кабинете не ограничен, доступ бесплатный.
Или напишите мне в telegram: @kirmark.