
## Веселитесь 🎉😁😆

Нельзя все время работать, это угнетает и продуктивность падает. Мы заметили, что наше приложение порождает не только практическую пользу, но и эмоции. Мы хотели поддержать это явление, и окрасить эмоции в более положительную окраску. Многим это покажется не существенным, а нам нравится, мы добавили эмоджи из коробки. Это удобный способ добавлять эмоциональную окраску 😁😂😆😭 в текстовые сообщения и медиа посты. Они могут помочь уточнить или усилить тон сообщения и сделать его более привлекательным для коллег. Кроме того, эмоджи могут быть полезны для упрощения коммуникации на разных языках, поскольку они часто используются для передачи концепций и идей, которые могут быть трудно выразить только словами.

![Эмоджи в Гулливер ЦРМ](/assets/images/philosophy/philosophy_5.png "Эмоджи в Гулливер ЦРМ")

Эмоджи также могут быть использованы для создания уникальных идентичностей и улучшения узнаваемости 🎓 группы, 🗽 списка или 🙏 проекта.


Веселитесь 🎉😁😆


## Рассылки

Добрый день! Мы заливаем обновление 4.11.4. Рассылки 💌.

1. Оно включает новую механику выбора нескольких клиентов в журналах 😵‍💫😎. Теперь есть возможность выбирать нескольких клиентов сразу через кнопку ctrl, что дает возможность выполнять действия сразу с несколькими клиентами, например можно выставить инвойсы сразу всем выбранным клиентам.

2. Добавили рассылки. Теперь смс (и др. сообщения) можно отправлять сразу нескольким клиентам. Существенно улучшили работу шаблонов смс 🧁. Стало очень удобно и просто сохранять смски как шаблон на будущее.

3. Добавили интеграцию с Яндекс почтой. У нас в планах целый набор возможностей, связанных с этой интеграцией 🐣🐤.

4. Добавили возможность экспортировать практически все таблицы 🍌🍉 и даже сам журнал для последующей аналитики. Мы стараемся следовать нашим принципам, в частности принципу Прозрачности. Мы не прячем основные функции под дорогими схемами ценообразования. Мы не скрываем наши планы, метрики и проблемы. Наконец мы смогли реализовать его на практике в полной мере и добавили возможность простого экспорта данных из нашей системы. Если вам, что-то не понравится, Вы всегда можете скачать ваши данные и использовать, как вам захочется.

5. Сделали фильтрацию клиентов в настройках адекватным рабочим инструментом. Теперь из фильтра клиентов можно не только создать списки, но и делать экспорт клиентов 👍💪.

![Цены мем](/assets/images/blog/prices_3.jpg "Цены мем")

6. Изменение цен! Следуя тому же принципу, (спасибо Жанна, Образовательный центр Полонез) мы пересмотрели подход к цене для больших компаний. Теперь процент с оборота будет постепенно снижаться при росте выручки, тем самым: чем вы больше, тем меньше ваши затраты на ЦРМ систему.

## Проблемы

1. Основная проблема над которой мы работаем прямо сейчас, это переделка ролей и прав, чтобы можно было кастомизировать роли под конкретные нужды, создавать свои роли и т.д. Насколько быстро мы с этим справимся трудно сказать, но мы работаем.
2. Идея с индивидуальными ценами на программу. Существет юзкейс, когда цена за занятия может устанавливаться на программу индивидуально для клиента и отличаться от остальных в группе. Это не реализовано. Но мысль отличная, будем проектировать.
3. Воронка не работает как должна, точнее она отлично работает, но многие хотят все процессы перенести внутрь Гулливер ЦРМ, включая первичные этапы воронки. Мы уже приняли решение, что будем делать чоткую😎 воронку с мощной аналитикой.

### Заключение

Спасибо за критику, благодаря Вам мы делаем систему каждый день лучше!

Удачи!


Рассылки 💌


## Задачи❤️‍🔥

Всем привет! На улице весна 💐🪻🌷, у всех хорошее настроение, и мы c отличным настроением выкатываем весеннее обновление 4.10.30 под емким названием 😃 **Задачи**.

В этом обновлении мы исправили все известные ошибки на сегодняшний день, добавили новую функциональность, упростили работу комментариев 💬, как вы просили 👻.

Теперь [**комментарии**](/user-guide/comments "Комментарии, статья") используются только для сохранения информации. У них больше нет статусов: **решен и не решен**, которые всех путали. Наша задумка не сработала и мы отказались от нее, о чем вам очень благодарны!! Теперь комментарии это просто комментарии, в них хранится информация и все, она не требует никакого действия.

### Канбан

Если надо что-то сделать и не забыть про это, то [**добавляйте задачи ☑️**](/user-guide/tasks "Задачи, статья"). У задачи можно поставить **исполнителя и дедлайн**. Таким образом вы ничего не забудете и не пропстите сроков. Задачи добавляются точно так же, как комментарии и привязываются ко всем сущностям системы 😎.

Для отображения всех ваших задач мы написали собственную канбан доску 🎯. Канбан – это известная визуальная система управления работой команды, одна из самых популярных методологий управления.
![Пример канбан доски](/assets/images/blog/tasks_1.jpg "Пример канбан доски")

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

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

Кроме того, канбан-доски способствуют **улучшению коммуникации внутри команды**🕹**️**🎮, так как участники видят общий прогресс и могут легко обсуждать приоритеты и распределение задач. Это помогает сократить время на согласование и принятие решений, что в свою очередь ускоряет выполнение проектов.

Подробнее о том как пользоваться задачами читайте в [**руководстве по задачам**](/user-guide/tasks "Задачи, статья").

### Еще в обновлении

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

### P.s. 🧩🏆

> Мы с нетерпением ждем ваш фидбэк😉, ваше мнение очень важно для нас. Мы внимательно прислушиваемся к вашим пожеланиям.


Задачи❤️‍🔥


## KISS😘 и Заумь

Сложно сделать что-то простое – это противоречие 😵‍💫, которое часто встречается в различных областях жизни, от искусства и дизайна до науки и технологий.

Парадоксально, но создание чего-то простого может быть гораздо сложнее, чем создание сложного и запутанного.

**Принцип KISS** (Keep It Simple, Stupid) 💋 – это философия, которая призывает к простоте и минимализму в дизайне, разработке и общении. Этот принцип гласит, что проекты, продукты или идеи должны быть максимально простыми, легкими для понимания и использования🌞.
Это один из самых главный принципов в разработке в нашей компании👍!

### Баланс между Простотой и Глубиной

Однако, принцип KISS💋 **не означает отсутствие глубины или сложности**. Он скорее призывает к тому, чтобы сложные вещи были представлены в простой и доступной форме. Важно найти баланс между простотой и содержанием.
Простота требует глубокого понимания предмета или задачи. Чтобы сделать что-то простое, нужно уметь выделить главное, отбросить лишнее и сосредоточиться на сути. Это требует не только технических навыков, но творческого подхода, интуиции.

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

![Кнопки лифта](/assets/images/blog/kiss_1.jpg "Кнопки лифта")

Кроме того, сложность заключается в том, что **простота должна быть универсальной и понятной для широкой аудитории**. Создать что-то простое, но при этом глубокое и значимое – это настоящее искусство 🎭.

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

### Борьба с Боязнью Простоты.

Иногда сложно сделать что-то простое из-за внутренних преград – эго, стремления к излишней оригинальности или желание произвести впечатление. Люди боятся показаться недостаточно умными. Люди, считающие себя творческими, — особенно. Авторы учебников — вдвойне. Дизайнеры — втройне. Однако именно в простоте и ясности кроется сила и эффективность💪.

Для маскировки используется заумь😵‍💫. Чем непонятнее выразился, тем лучше — никто не обвинит в отсутствии оригинальности. Если бы миром заведовал среднестатистический дизайнер, то на дорогах вместо белых полос разметки были бы виньетки в стиле хохломы, палеха и гжели. Красиво ведь.

### Метод "Резинового Утенка"

Как только мы не можем простыми словами описать задумку или улучшение, значит мы не понимаем что делаем. Метод “резинового утенка”🦆 придуман не сегодня. Еще в 60-х годах прошлого века физик Фейнман сформулировал подход: Если вы не можете объяснить “на пальцах” то, чем вы занимаетесь, то вы не знаете, чем вы занимаетесь. Обычно для этих целей используют детей, жен, тещ, случайных попутчиков, собак и, наконец, когда “живые слушатели” закончились, наступает очередь игрушек .

![Утенок](/assets/images/blog/kiss_2.jpg "Уточка")

Гениальный по простоте метод:

1. При наличии проблемы или задачи - ставим перед собой резинового утенка (можно заменить на любое иное существо, игрушку или явление).
2. Начинаем пошагово, построчно, подробно и максимально понятно объяснять решение задачи.
3. Перечисляем все свои решение, шаги, озарения.
4. Пересказа проблемы или ситуации от третьего лица способствует быстрому поиску идеального решения.
5. Конец!

### Деление на Два

Многие гуру дизайна утверждают, что всегда можно упростить интерфейсы в два раза🍒. Мы думаем, что это значение усреднено😃. Иногда удается упростить в три раза иногда в полтора, а иногда упростить не получается.

![Эволюция интерфейсов в телефонах](/assets/images/blog/kiss_3.jpg "Эволюция интерфейсов в телефонах")

Со временем, все упрощается, медленно, но упорно и достигает уровня простоты, когда нечего упрощать. Это прекрасно!

### Заключение

Мы используем принцип KISS, боремся с боязнью простоты, делим на два и «разговариваем с уточками» максимально простыми словами везде, где только можно и стараемся все сделать максимально просто, насколько хватает ума и таланта 🦧. Если мы найдем возможность что-то еще упростить, мы обязательно его упростим.


KISS😘 и Заумь


### Обновление 4.9.10: Кабинет клиента

Добрый день! На дворе настоящая зима, а мы готовы рассказать над чем мы работали.

Мы выкатили новую версию 4.9.10, содержащую более тысячи изменений и улучшений, в основе которой реализован функционал кабинета клиента и реализованы сопутствующие задачи обеспечивающие распределение прав доступа и безопасности.

1. Написали веб версию кабинета клиента [**подробнее…**](/user-guide/customer-area "Кабинет клиента, статья") (отдельная механика регистрации, улучшили систему разграничения прав доступа по ролям RBAC (Role based access control), собственный компонент журнала для клиентов);
2. Продолжали улучшать документацию;
3. Исправили ошибки большие и маленькие;
4. Избавились от «styled-components»;
5. Провели обновление всех клиентских библиотек до последних версий;
6. Перешли на последний Typescript;
7. Покрыли автоматическим тестами почти весь код;
8. Радикально сократили инженерный долг;
9. Обучали новых клиентов и помогали старым, внимательно собирали пользовательский опыт и отзывы;
10. У нас вышла [**статья**](/blog/post/nets "Как мы используем сети 🥅 для определения приоритетов в разработке") как мы определяем приоритеты разработки;

Не смотря на мороз в комманде отличное настроение, а это случайная картинка из нашего внутреннего чата 😀😁
![Мем](/assets/images/blog/\customer_area_1.jpg "Как мы делаем Гулливер ЦРМ")

Таким образом, мы продолжаем активно работать в четырех направлениях:

1. улучшение функциональности (добавляем, исправляем),
2. улучшение документации,
3. развитие continuous integration and continuous delivery (CI/CD),
4. разработка портала мониторинга сервиса.

**Кроме того мы продолжаем ранний доступ**

[Ранний доступ](/blog/post/early-access "Ранний доступ") — модель разработки, с помощью которой пользователи получают доступ к предварительной полной версии приложения, а разработчики используют полученный фидбек для доведения приложения до полноценного выпуска. Те, кто участвую в раннем доступе, как правило, помогают в отладке программы, дают обратную связь, вносят предложения по улучшению.

Этот этап является бесплатным. Все платежи являются не обязательными. При этом для вас будет доступен весь функционал системы, техподдержка и т.д. Сроки окончания раннего доступа, пока не определены.

### Основные ближайшие задачи

1. Ппеределка комментариев, добавление возможности ставить задачи и сроки;
2. Улучшение документации;
3. Новые интеграции (Viber);
4. Возмоности рассылок сообщений
5. Разработка партнерской программы
6. Исправление ошибок и др.

**P.s.**

Спасибо, что потратили время на прочтение. Мы ждем свежих заявок на подключение, отзывов, и будем делать все, чтобы gullivercrm.com работал лучше


Кабинет клиента


## Как мы используем сети 🥅 для определения приоритетов в разработке

Определение порядка разработки 👻 продукта – одна из самых сложных проблем в управлении продуктом. Мы сталкиваемся с этой проблемой каждый день! Существует множество техник, которые могут помочь в решении. В двух словах, эти техники – чаще всего линейные модели, которые с такой же эффективностью, как интуиция опытного менеджера по продукту. В большом перечне подходов не хватает одного важного элемента - сети.

### Сеть фич

Любую 🧑‍🔬🔬 систему можно представить в виде сети. В нашем случае мы работаем с программным продуктом. Каждый узел представляет собой отдельную фичу (функциональность). Все фичи связаны между собой определенными связями, они зависят друг от друга. Возьмем Гугл документы. Есть фича "Документ" и фича "Поиск". Поиск связан с документом, поскольку вы постоянно что-то ищете в документах. Абстрактная сеть функций выглядит как-то так:

![Пример сети фич](/assets/images/blog/nets_4.jpg "Пример сети фич при разработке Гулливер ЦРМ")

Основная идея проста: важность фичи определяется **связностью**. Больше связей - выше важность. Меньше связей - фича менее важна.
В целом, менее важные фичи будут довольно одинокими и изолированными (у них будет меньше связей и они будут находиться на периферии сети), в то время как важные - будут составлять ядро сети. Мы называем хорошо связанные фичи основными. Вы можете сразу почувствовать, что это несколько похоже на алгоритм PageRank от Гугл. Похоже, каждый узел - это страница, а связи определяют важность страницы.

Одинокие фичи могут быть тупиковыми ☠️, а могут открывать новые горизонты 🌈. Они могут быть там по какой-то причине. Например, вы можете исследовать новые возможности и новые области применения продукта. В Гугл документах это могут быть видеозвонки. Они по-прежнему связаны с такими функциями, как Авторизация, Профиль пользователя, но в целом это периферийная функциональность.
Так как же выбрать что разрабатывать и в каком порядке?

### Мы считаем, что добавление 5 слабо связанных между собой фич - плохая идея.

Кстати, такая ситуация не редкость. У вас всегда есть целый набор запросов со стороны клиентов, и если вы используете какую-нибудь линейную модель вроде RICE, то эти несвязанные функции попадают в следующий релиз, при этом может оказаться, что у них мало связей.
По сути, это похоже на стратегию «Spray and pray» 🙏, когда вы пытаетесь исследовать десятки разных областей без глубины. Этот термин означает стрельбу из автоматического огнестрельного оружия по врагу длинными очередями без прицеливания. Почти во всех случаях такое поверхностное поведение оборачивается катастрофой для продукта. Именно поэтому линейные модели могут не работать на практике, а использование сети фич помогает получать более точное представление о приоритетах.

![Добавление периферических фич](/assets/images/blog/nets_3.jpg "Добавление периферических фич в Гулливер ЦРМ")

### Добавление нового кластера фич - это настоящее исследование.

Это означает, что вы пытаетесь исследовать новую область с помощью набора последовательных связанных фич. В принципе, когда вы пробуете новую область, она может быть слабо связана с ядром продукта 🔬, но, скорее всего, она образует новый цельный кластер. При этом вы всегда должны думать о совершенно новом продукте или новом модуле, который можно включать/выключать. Многие IT компании придерживаются этой стратегии с большим успехом. У нас целым отдельным кластером является коропоративная вики и списки. Они представляют собой целые кластеры фич, которые связаны с ядром продукта небольшим количеством связей.
Обратите внимание, что этот подход хорош, когда ядро продукта достаточно прочное и вы не можете найти новые точки роста внутри ядра. Другая ситуация, когда это может сработать, - кризис. Когда основная функциональность не находит применения на рынке, нужно как можно быстрее попробовать новые области, и это может быть хорошим способом сделать это.

![Добавление кластера фич](/assets/images/blog/nets_1.jpg "Добавление кластера фич в Гулливер ЦРМ")

### Фичи связанные с ядром приложения.

Это настоящее мясо 🥩. Вы почти всегда улучшаете основную функциональность и основной фокус продукта, добавляя суперсвязанные функции. Представьте, что в Гугл документах у вас есть документы, электронные таблицы и презентации, но нет поиска. Новая функция поиска затронет все эти области и значительно улучшит основной пользовательский опыт.

![Добавление фич, связанных с ядром](/assets/images/blog/nets_2.jpg "Добавление фич, связанных с ядром в Гулливер ЦРМ")

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

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


Определения приоритетов в разработке


Добрый день! Прошло немного времени и мы готовы поделиться новостями.

**Сначала результаты**

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

Оказалось, что цели подключения к системе могут быть совершенно разнообразны 💘. Кто-то всерьез со старта начинает пользоваться. Некоторые клиенты хотят просто покликать и посмотреть, что под капотом. Некоторые настойчиво просят о подключении, но даже не заходят в приложение. Это забавно, и стало для нас целым бизнес открытием.

Вторым важным результатом стало большой рост отзывов о системе, так называемый фидбэк 🙊🙉🙈. Это тоже круто. У нас появилось очень много полезных данных для совершенствования, которые не лежат на поверхности. Мы очень благодарны за ваши отзывы и конечно критику. Однако, мы начали сталкиваться с трудностями систематизации отзывов. В дальнейшем, возможно потребуется автоматизация этого процесса с голосованием за новые фичи и порядок дальнейшей разработки.

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

Четвертое. Рост количества клиентов продиктовал необходимость усовершенствовать работу. Мы упорядочили подход к взаимодействию с клиентом, разработали гибкую систему взаимодействия и назвали ее [**«Консьерж-сервис»**](/concierge "Консьерж-сервис"). Она включает индивидуальный подход 🤹‍♀️, настройка системы под конкретные нужды, постоянное обучение и поддержка компаний 🧙‍♂️. Мы всегда на связи и готовы отвечать на ваши вопросы.

Пятое. Можно с осторожностью сделать вывод, что мы вплотную к Market-Fit (соответсвуем рынку)🎢, но можем быть еще лучше проще и удобнее.

Шестое. Третьего августа у нас упал сервер на два часа 🖤. Без этого никак...🏴‍☠️ Мы разобрались в причинах и теперь лучше понимаем в какую сторону и какими технологиями совершенстовать, а главное масштабировать архитектуру.

Седьмое. Мы провели открытое обучение для всех желающих работе в Гулливер ЦРМ с Ольгой Урываевой в виде трехдневного семинара и на основе его разработали программу обучения для нашего Консьерж сервиса. К сожалению из видео семминара, который мы записали не получается сделать что-то приличное для YouTube канала, поэтому видео будем записывать специально. Кроме того постоянно пишем и исправляем обучающую [документацию](/user-guide "Руководство по Гулливер ЦРМ") .

**Чем мы занимались?**

Каждый день наполнен плановой работой и мы постоянно что-то улучшаем.

1. Написали интеграцию с ERIP, EPOS (Express-Pay) с QR кодами. [**Подробнее…**](/user-guide/express-pay "Интеграция с ерип и епос")
2. Написали интеграцию с Rocket SMS для рассылки SMS, можно отсылать СМС сообщения прямо из приложения с отслеживанием статусов доставки сообщений. [**Подробнее…**](/user-guide/rocket-sms "Интеграция с сервисом СМС рассылок")
3. Написали собственное расписание, как один из вариантов отображения групп. Расписание поддерживает множественные правила повторений событий, а также механику драг энд дроп. Т.е. теперь группы могут заниматься в разные дни в разное время в разных кабинетах. [**Подробнее…**](/blog/post/new-month-new-release "Расписание в Гулливер ЦРМ")
4. Добавили сущность кабинет (помещение), для привязки расписания к кабинетам.
5. Проводим эволюцию программной серверной архитектуры.
6. Провели существенное увеличение мощности серверного кластера.
7. Переделка сохранения изображений в собственное и хранилище изображений (в тесте).
8. Совершили переезд на новый движок для WIKI, теперь работать с текстовыми документами стало еще проще и быстрее.
9. Обновили интерфейс клиента, клиентам добавили фильтр с открытыми инвойсами.
10. Обновили логику работы бота, кроме всего он будет стараться найти клиентов, которым не выставили инвойс и писать этому клиенту комментарий.
11. Переделали профиль пользователя, добавили функциональность для более простой работы с правами и ролями.
12. Обновили логику работы цен. Добавили возможность изменять и удалять цену если она еще не вступила в силу.
13. Обновили вторичные библиотеки до последних версий. Все ошибки, что были известны на момент написания статьи починили, провели сотни мелких исправлений и улучшений и др.

**Мы продолжаем ранний доступ**

[Ранний доступ](/blog/post/early-access "Ранний доступ") — модель разработки, с помощью которой пользователи получают доступ к предварительной полной версии приложения, а разработчики используют полученный фидбек для доведения приложения до полноценного выпуска. Те, кто участвую в раннем доступе, как правило, помогают в отладке программы, дают обратную связь, вносят предложения по улучшению.

Этот этап является бесплатным. Все платежи являются не обязательными. При этом для вас будет доступен весь функционал системы, техподдержка и т.д. Сроки окончания раннего доступа, пока не определены.

**Основные ближайшие задачи**

1. Написание кабинета клиента;
2. Улучшение документации;
3. Новые интеграции;
4. Исправление ошибок и др.

**P.s.**

Спасибо, что потратили время на прочтение. Мы ждем свежих заявок на подключение, отзывов, и будем делать все, чтобы gullivercrm.com работал лучше


Новый месяц - новый релиз


## Расписание

В этой статье мы в особой литературной форме подробно расскажем о том как мы делали и делаем расписание в Гулливер ЦРМ.

## Зачем?

Одной из ключевых функций систем автоматизации является планирование и управление мероприятиями в компании. Для этого используется такой инструмент как **расписание** . Эффективное использование расписания в ЦРМ системах может принести множество преимуществ.

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

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

**В-третьих**, использование расписания помогает **улучшить коммуникацию и координацию** внутри компании. ЦРМ система позволяет сотрудникам видеть расписание работы других коллег, делиться информацией о клиентах и обсуждать задачи в режиме реального времени. Это способствует более эффективной командной работе и улучшению внутренней коммуникации.

**Использование расписания** в ЦРМ системах помогает **повысить прозрачность и контроль** над процессами. Это позволяет быстро выявлять проблемные области и принимать меры для их улучшения.

## Требования к расписанию в Гулливер ЦРМ

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

Сложности возникают, когда мероприятие повторяется с определенным интервалом. Проблема конечно заключаются в многообразии вариантов повторения. Например, каждый день, каждый понедельник, каждые выходные, каждый первый вторник сентября, каждый месяц, каждый год (день рождения), каждое 29 февраля (каждые 4 года). Как видите вариантов повторения достаточно много.

С точки зрения обычного человека, это просто и понятно, но с точки зрения информационных систем, это не является тривиальной задачей… Добавляют сложности «несимметричные события». Например, логопед занимается с клиентом каждый вторник в 12.00 в большом кабинете, и каждую пятницу в другое время в 14.00 в кабинете для логопедов. Как вы видите, к разному времени могут добавляться разные помещения.

И это еще не все, длительность занятий в разные дни также могут отличаться, а значит у нас добавляется дополнительная прослойка сложности.

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

## Наша реализация

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

![Расписание](/assets/images/blog/schedule_1.jpg "Расписание в Гулливер ЦРМ")

Расписание представляет собой актуальный месяц неделю или день. ВЫ можете выбрать каким образом вам необходимо его отображать. В расписании у нас предусмотрена удобная фильтрация по филиалам, программам, помещениям или по названию группы для быстрого поиска. При активации фильтра в расписании будут отображаться только группы, которые соответствуют фильтру.

При добавлении в расписание меню включает разделы выбора группы, помещения, а также выбора длительности и периодичности мероприятия. Раздел "Уже в расписании" показывает есть ли данная группа уже в расписании.

![Добавление группы в расписание](/assets/images/blog/schedule_2.jpg "Добавление группы в расписание")

При нажатии на длительности **"Весь день"** можно выбрать длительность мероприятия. А при нажатии на кнопку **"Однократно"** можно задать дату начала повторений, периодичность и когда закончить повторения мероприятий.

Таким образом можно:

1. Выбрать группу
2. Выбрать помещение
3. Выбрать время 12.00-12.45
4. Выбрать старт с 01.09.2023
5. Выбрать периодичность: каждый четверг и пятницу
6. Выбрать когда закончить: 31.05.2024

И ваша группа будет повторяться весь учебный год с 01.09.2023 по 31.05.2023 каждый ЧТ и ПТ с 12.00 по 12.45 по такому расписанию.

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

![Расписание](/assets/images/blog/schedule_3.jpg "Изменение расписания в Гулливер ЦРМ")

## P.s. 🧩🏆

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


Как мы делали и делаем расписание


### Сначала результаты закрытой беты

Сделали море работы, а может больше.

### В общем

Переход на новые технологии включая Nestjs, тайпскрипт... оказался мега правильными решением. Все стало проще, быстрее. Структура серверного кода понятна, прозрачна. Стало гораздо легче вылавливать баги и разрабатывать дополнительный функционал. Сделали много работы по адаптации интерфейсов к малым экранам. Провели стандартизацию элементов пользовательского интерфейса, попытались добиться более-менее приличного UX. Переписали полностью вики. Написали полностью списки. Написали прототип автоматизации.
В команде +1 человек. Написали собственный сервис контроля и мониторинга SAAS, подключили Feature Toggle. Начали разработку документации пользователей. Естественно фиксили баги...

### Журнал

Пришлось написать полностью свой реакт компонент с нуля. И мы совсем не жалеем потраченных усилий. То как он работает сейчас очень круто. в Журнала добавили кастомные сортировки, изменили способ подгрузки данных, оптимизировано быстродействие журнала, добавили мультиселект, можно выбирать и изменять сразу несколько ячеек одновременно. Работает хорошо. Столкнулись с тормозами на больших и старых журналах. Провели оптимизацию компонентов, data-flow. Сейчас масштабируется отлично.

### Биллинг

В биллинг почти не лазили. Работает хорошо. Добавили комментарии ко всем финансовым документам. Написали нормальное представление для малых экранов.

### Вики

Много экспериментировали с Вики, загрузкой изображений в собственное облако, публичным api. Инструмент востребован, но не так как комментарии конечно. В редактор, который мы взяли за основу плохо интегрируются новые плагины. Думаю, еще переделаем...

### Комментарии

Комментарии усложнились. У них есть статус: **решен**, **не решен**, а также **просмотрен**, **не просмотрен**. Если сущность (например, платеж) прокомментирована, на ней отображается специальная иконка комментария 💬. Бывает два вида комментариев, требующие решения вопроса (иконка с точкой) или нет (иконка без точки).

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

### Списки

В результате тестирования, мы поняли, что ряд бизнес-процессов наше приложение не покрывает. В частности, маркетинговую сегментацию, и формирование воронки продаж. Для их решения мы придумали новый инструмент и полностью его реализовали. Списки - мощный инструмент с широкими возможностями кастомной фильтрации и сортировки, с возможностью совместного редактирования, прямо внутри системы, у которого в доступе уже есть все наши клиенты 🆒. Мы осознали необходимость этого инструмента не сразу. Но после разработки его прототипа, поняли, что это просто бомба 💣💣💣. **Списки** могут решать очень много проблем. Они настраиваются, они автоматизируются, в них есть предустановленные сущности в виде филиалов, ваших программ, пользователей и т.д.

Списки нужны для гибкой сегментации клиентов по различным признакам c богатыми возможностями автоматизации, фильтрации, сортировки и экспорта

### Отзывы

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

### Открываем ранний доступ

Мы наконец добрались до следующего этапа разработки. Мы назвали его "ранний доступ".

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

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

Этот этап является бесплатным. Все платежи являются не обязательными. При этом для вас будет доступен весь функционал системы, техподдержка и т.д. Сроки окончания раннего доступа, пока не определены.

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

### Основные цели

Продолжение разработки и совершенствование gullivercrm.com
Подключение инструментов поддержки комьюнити
Стабилизация сервиса технической поддержки пользователей
Улучшение документации
Кластеризация

### P.s.

Мы ждем свежих отзывов, и будем делать все, чтобы gullivercrm.com стал лучше


Ранний доступ


## Цена и стоимость

Добрый день! Эта статья про наш взгляд на ценообразование на программные платформы, занимающиеся автоматизацией группового учета клиентов. Мы попытаемся объяснить, как мы пришли к такой цене на Гулливер ЦРМ, какой механизм выработали.

История взглядов на цену и стоимость за последний несколько веков претерпела существенные изменения. Об этом можно почитать в соответствующей специализированной литературе (Аристотель, Фома Аквинский, Адам Смит и др.). Нам наиболее близка позиция Австрийской школы экономики, которая отказалась от объективной концепции стоимости. Мы согласны с тем, что цена не является денежным отражением стоимости, она отражает баланс субъективных оценок продавцом и покупателем предельной полезности товара, в нашем случае приложения. Несмотря на субъективность оценки, все стороны процесса пытаются объективизировать на сколько цена справедлива. И в вопросе справедливости цены у нас есть несколько мыслей, которыми хотим с вами поделиться.

Основные варианты, которые сейчас существуют в этом сегменте ЦРМ систем.

#### Фиксированная цена.

Очень хороший вариант, для пользователя. Прозрачный понятный, фиксированные затраты отлично считаются, учитываются при планировании. Но обладает недостатком для создателей программного продукта. Возникает дисбаланс. Наблюдается совершенно разная нагрузка на систему у педагога-предпринимателя, которые один сам ведет занятия и многофилиальной сети с 40 сотрудниками, а оплата одинаковая, фиксированная. Так как бесплатного ничего нет, электричество место на диске, мощности системы будут закладываться в среднюю цену. Получается малые игроки будут переплачивать, а большие не доплачивать. Фиксированная цена плоха. Второй особенностью является отсутствие учета сезонности групповых занятий. Летом-то мы не работает или работаем совсем мало. Ни йога, ни языковые курсы, ни детские центры не могут поддерживать такую же загрузку, а оплата фиксированная. Хоть дождь хоть снег – плати. В этом случае, получается, что переплачивают маленькие игроки, и все в летние месяцы.

![Цены](/assets/images/blog/prices_1.jpg "Цены")

#### Цена зависит от количества модулей.

На рынке есть системы, которые разрабатывались десятилетиями. Созданы “программные монстры”. Бывает так, что большинством функций пользователи даже не пользуются. Когда разработчики узнают, что часть системы нужна только узкому кругу, они вносят в систему возможность отключать некоторые модули, чтобы за них не платить. Вроде разумно. Оплата, зависит только от количества включенных модулей. Пользуйтесь только частью монстра!
Модульная система плоха. Из-за большого количества модулей пользователи не понимают, что им надо, что нет, нет времени вникать и разбираться. Все усложняется со временем, не понятно нужны ли определенные модули сейчас, будут ли нужны завтра. Возможность временного отключения модулей, призванная решать проблему, ее только усугубляет. Все время есть дилемма. Оставить включенными или отключить. Другими словами, пользователям нужно держать этот вопрос в памяти, тратить время, чтобы поддерживать актуальный набор оплачиваемых модулей.
Мы думаем, лучше тратьте свое драгоценное время на отдых или улучшения своего продукта. Люди ленивы по своей природе, информации так много, а времени так мало, что при модульной системе приложения пользователи всегда переплачивают. Такие системы-монстры отвратительны, на наш взгляд они живы благодаря большой инерции b2b сегмента программного обеспечения, либо отсутствия конкуренции.

#### Цена зависит от количества клиентов.

Второй вариант справедливой цены, это цена за количество клиентов. Отличный вариант. Только он отвратительно работает в сегменте, который автоматизируем мы. Почему? Потому что групповые занятия (языки, спорт, йога, музыка, развивашки) невероятно динамичны. Вы можете прийти заниматься английским или пением в сентябре с одними друзьями, а закончить год совершенно в другой группе. Если бизнес работает хорошо, этот процесс менее выражен, но дрейф клиентов неизбежен. Всех бросивших заниматься администраторы пытаются вернуть и держат в клиентах до последнего, и платит за него, а он не ходит и не будет. Таким образом клиентская система плоха. В некоторых системах есть разбежка клиентов 10-20 одна оплата, 30-100 другая, 200-500 третья. Выбирай какую хочешь. Но что делать, если у вас 21, 101, 201 клиент. Один лишний клиент и вы платите кратно больше, плюс один клиент и оплата вырастает на 20 процентов. Эта ситуация усугубляется сезонностью, сколько человек летом ходит на музыкальные занятия? Кратно меньше, а может в этом году будет больше? Мы не знаем, мы предполагаем, и берем тариф, соответствующий нашим ожиданиям, а не фактической посещаемости. При такой системе пользователи всегда переплачивают. Непорядок.

#### Цена зависит от количества модулей и клиентов.

Хуже предыдущих двух вариантов может быть только их комбо, зависящая от них двоих. Если взять плохой вариант к нему добавить еще один плохой вариант, получится ли что-то хорошее? Вряд ли. Сложность выбора и рост опций выбора приводит к тому, что выбрать правильно становится еще тяжелее. Более того добавляется еще чувство под название "Муки выбора"...

#### Цена зависит от количества пользователей.

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

#### Наша цена

Эта статья является результатом продолжительного обдумывания по поиску варианта, который был бы на стороне пользователя и при этом учитывал наш интерес, как разработчика. Мы поняли, что надо исключить возможность несправедливых переплат, снизить контроль за системой со стороны пользователя, убрать несправедливость фиксированной цены. Естественно в таких сложных вопросах золотого стандарта не существует, а лучший вариант является самым тонким компромиссом.
После долгих обдумываний мы его нашли. Наш вариант цены – это маленький процент от продаж (0,5% +5$ на кофе разработчикам ежемесячно). Все.

![Цены на Гулливер ЦРМ](/assets/images/blog/prices_2.png "Цены на Гулливер ЦРМ")

Вам без разницы сколько у вас клиентов, или пользователей вы платите только с их платежей. Никаких модулей, всем пользователям доступна одинаковая система, с полным набором функционала. Не надо тратить время на выбор тарифа модулей и подсчет клиентов. Летом не работаете – не платите, есть у вас “полтора” клиента, платите только 0,5% от их платежей. Есть у вас 1000 клиентов, платите 0,5% от их платежей.

Здесь есть один тонкий психологический момент, связанный процентами и абсолютными цифрами. Иногда 0,5% может стать довольно увесистой цифрой в абсолютном значении. Это говорит о том, что ваш бизнес процветает. Поздравляем. Мы его предлагаем компенсировать мыслью о том, что ценность системы резко возрастает с ростом клиентской базы. Вот пример, если у вас 5 клиентов, вам ЦРМ-то и не нужна, если 50 можно и руками разнести на листике, если 500 ошибки и потери неизбежны. Мы четко понимаем, что ценность нашего продукта возрастает с ростом клиентов и выручки. Не смотря на это, мы стараемся сделать все, чтобы вы чувствовали не только пользу, но и удовлетворение. Поэтому мы разработали автоматическую систему снижения процента при росте ваших доходов. Чем больше ваш доход тем меньший процент вы заплатите. Это просто отлично!

Еще один момент, многие банки за осуществление платежей берут ревенью, достигающее в разных странах до 3%. В Беларуси в среднем 2% при этом они не несут вашему бизнесу никакую пользу. Мы считаем это не очень честно, но как есть. Самым простым решением, является добавить к цене ваших занятий 0,5% и забыть об этом вопросе, то есть занятия, которые стоили 100 рублей станут стоить 100 рублей и 50 копеек. Потеряете ли вы от такого решения хоть одного клиента, я уверен нет, а вот профит, который вы получите от использования системы несоизмерим.

Основными преимуществами являются:

1. Простота
2. Вы никогда не переплачиваете
3. Не тратите время и усилия на коррекцию тарифного плана из-за изменившихся обстоятельств.
4. Всегда платите по окончанию месяца, без предоплаты

На этом все, спасибо что дочитали до конца.


Цена и стоимость


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

### Что сделали:

- Весь проект полностью перевели на Typescript, чего и вам желаю 💡
- Весь клиент переписали на MaterialUI 🎨;
- Написали первый прототип Википедии 🎪
- Написали первый прототип комментариев 💬
- Снова переписали журнал на другом инструменте (MaterialUI Grid) 👷‍♂️

### Подробнее

Осуществили переход на тайпскрипт всего проекта, включая бэкенд. Просто невозможно разумно писать такую систему без строгой типизации. Постоянное внесение изменений в код вело к немыслимому количеству багов связанных со структурой данных. Фронтенд переписали на MaterialUI, интегрировали Redux и ряд других библиотек, без которых современный фронтенд немыслим. MaterialUI очень нам нравится, очень хорошая документация, темизация из коробки, отличный API.

Полностью переписали бэкенд: перешли с чистого Express на Nestjs. Переход хоть и сопровождался большим объемом работы, однако структурировал серверный код, его легче править и поддерживать, тоже кстати на тайпскрипте. Результат выглядит прекрасно. Вместе с Nestjs переписали серверный валидатор.

Для понимающих, за этот год фактически написали новое приложение.

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

### Журнал

Вместе с переходом на тайпскрипт, полностью переписали журнал. Я посчитал это уже 3 вариант. Мы столкнулись с тем, что готовые инструменты, так называем Rich Tables из коробки работают не так как нам необходимо и мы от них в последствии отказались (devExpress, ag-grid). Снова переписали журнал на другом инструменте (MaterialUI Grid), похоже это рабочий вариант, но это не точно 😣😮

### Биллинг

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

### Релиз википедии

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

### Релиз комментариев

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

### Отзывы

В целом, отзывы пользователей можно описать как "норм". Конечно, хотелось, чтобы отзывы были более восторженными. Но как есть. На рынок выпускать рано. Но в закрытую бету в самый раз.

### Технологический стек

Несколько изменений:

- Начали интеграцию Typescript
- Внедрили Redux и Redux Thunk
- Добавили Reselect и селекторы
- Перешли на MaterialUI

### Стартуем закрытое бета-тестирование

На бету мы выходим уже с 4 большими структурными компонентами (журнал, биллинг, комментарии, вики). Больше плодить пока не планируем. Надо с этими разобраться.

Тестирование будем проводить на той же базе, детском клуб Гулливер. Также к тестированию привлечем еще музыкальную школу [Музыкальная академия](https://www.muzacademia.by/ "Музыкальная академия") в городе Минске. Предварительное согласие мы получили. Посмотрим, как наше приложение себя чувствует в условиях индивидуальных занятий.

В википедии написано:

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

Это и сделаем нашей целью!

### Технологический стек

Несколько изменений:

- Полностью перешли на Typescript
- Переписали весь state на Redux
- Полностью переписали все на MaterialUI
- Перешли с чистого Express на Nestjs, пришлось переписать весь сервер, да Typescript в Nestjs из коробки. Отличное решение!

### P.s. 🧩😕

- После долгих дебатов, мы поняли, что нейминг это не наше. Приложение решили назвать Гулливер ЦРМ в честь клуба на котором мы запустили систему впервые. Доменное имя gullivercrm.com оказалось свободным. (😁😂)
- Почти полностью переписали код опять оО
- В команде 3 человека (🐱💻🐱👓🐱🚀)
- Четыре рабочих компонента - Журнал, Биллинг, Комментарии и Вики


Закрытое бета-тестирование


# Жизнь клиента

В этой статье мы подробно расскажем о клиентах.

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

### Этапы жизни клиентов

Почему не все клиенты одинаковы? Каждый клиент в вашей компании проживает так называемую **жизнь клиента**, включающую этапы **рождения** (записался на занятия), **активного существования** (активно ходит на занятия), и **смерти** (Закончил курс или бросил). Эти термины являются аналогией на обычную жизнь, и используются для удобства понимания. Попытаемся объяснить подробнее. Каждый клиент рождается, когда проявляет интерес посетить ваши занятия (это может быть телефонный звонок, заявка с сайта, социальных сетей или промо акций). Этот потенциальный клиент называется **Лид** (устоявшийся термин из маркетинга). В нашей системе любой клиент добавленный в систему получает статус **Лид**.

После того как с лидом проведена работа, подобрана программа, группа посещения, расписание мы назначаем ему первое (пробное) занятие и в этот момент он переходит в статус **Новый** клиент.

После того как клиент посещает первое занятие, он получает статус **Активный.** И сохраняет его весь период хождения на ваши занятия. Это может быть месяц, год 5 лет. Весь период активного хождения клиент приносит вам доход. Чем дольше к вам ходит клиент, тем лучше, вам не требуется искать новых клиентов на его место.

Когда клиент не планирует дальнейшее посещение занятий и перестает ходить на занятия он отправляется в архив и получает статус **Архивный.**

Таким образом, жизнь клиента в системе представляет собой четыре этапа: **Лид, Новый, Активный, Архивный.** Они всегда отображаются в виде специального беджа рядом с клиентом, поэтому определение статуса клиента никогда не вызывает проблем.

![Статусы клиентов в Гулливер ЦРМ](/assets/images/blog/clients_1.jpg "Статусы клиентов в Гулливер ЦРМ")

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

Для чего это нужно? Жизнь клиента — это этапы **воронки продаж** (еще один устоявший термин из маркетинга). Потери на каждом этапе воронки продаж по разным причинам ведут к снижению выручки в целом. Таким образом одной из важнейших задач менеджмента является оптимизация потерь на этапах жизни клиента (этапах воронки продаж), а системы автоматизации – помощь в структуризации и систематизации этого бизнес процесса. Нужно стараться, чтобы люди, проявляющие интерес, превращались в лидов. Чтобы больше лидов записывалось на первое занятие, чтобы больше клиентов после первого занятия превращались в активных клиентов, и чтобы в этом статусе они максимально долго сохранялись. Методы, которыми это достигается на каждом этапе различные (бывают эффективные и не очень), но все они лежат за рамками систем автоматизации.

Хочется отметить, что в нашем приложении не нужно вручную отслеживать состояние клиента, это выполняет сама система.

Добавляя нового клиента в систему, он получает статус **лид**, это происходит автоматически. Смотри ниже.

![Лид в Гулливер ЦРМ](/assets/images/blog/clients_2.jpg "Лид в Гулливер ЦРМ")

Записав на пробное занятие, он получает статус **Новый.** Также автоматически. Пробное занятие в журнале отмечается голубым цветом.

![Новый клиент в Гулливер ЦРМ](/assets/images/blog/clients_3.jpg "Новый клиент в Гулливер ЦРМ")

Отмечаем первое посещение зеленым, и клиент получает статус **Активный.** Кроме статуса, все активные клиенты всегда и везде отображаются ярким контрастным цветом (например, в журнале) и отображаются всегда в верхней части списка. Каждый раз, когда мы в журнале ставим зеленую ячейку клиент, признается активным, ведь он посетил занятия. Это может длится неделю, а может 5 лет, зависит от специфики бизнеса и приверженности клиента посещениям занятий.

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

![Отправка клиента в архив в Гулливер ЦРМ](/assets/images/guides/journal/journal_10.jpg "Отправка клиента в архив в Гулливер ЦР")

### Воронка продаж

Для того чтобы отслеживать клиентов в разном статусе в компании можно воспользоваться нашим инструментом под названием **Списки.** Этот инструмент позволяет достаточно гибко подойти к работе с лидами, новыми клиентами и т.д. В зависимости от количества клиентов, филиалов, вы можете сделать один список либо несколько в зависимости от статуса, филиала и т.д.

![Списки в Гулливер ЦРМ](/assets/images/features/lists/lists_4.png "Списки в Гулливер ЦРМ")

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

### Системное окно клиенты

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

![Фильтр клиентов в Гулливер ЦРМ](/assets/images/guides/basics/basics_12.jpg "Фильтр клиентов в Гулливер ЦРМ")


Жизнь клиента ⏲


## Комментируй все

Люди прекрасны! Одной из отличительных особенностей вида «Человек разумный» является его неутолимая жажда общения. Мы разговариваем со всеми и обо всем. Эволюционная польза общения многократно научно обоснована и доказана. Но для нас, как создателей системы автоматизации общение является механизмом для переноса информации. Есть одна проблема, при живом общении происходит искажение, деградация информации, ее постепенна утрата. Никто в полной мере не вспомнит, о чем говорил уже неделю назад. Это плохо, если информация, которую передавали полезна бизнесу.

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

Мы попытались решить эти проблемы создав **комментарии**. Это довольно мощный инструмент сохранения, циркуляции и доставки информации внутри компании. Но вы можете сказать, что комментарии есть много где, и окажетесь правы. Отличие нашего инструмента заключается в том, что в нашей системе вы можете комментировать всё..., все сущности, которые есть в системе 🎠. На наш взгляд, очень важно понимать, что конкретно вы комментируете: цену, урок, клиента или платеж... Это сохраняет большое количество невербальной информации и говорит об обстоятельствах его написания и т.д.

![Пример решенного комментария](/assets/images/features/chats/chats_2.png "Пример решенного комментария в Гулливер ЦРМ")

Если сущность (например, платеж, возврат, цена, группа и др.) прокомментирована, на ней отображается специальная иконка комментария 💬. Бывает два вида комментариев, требующие решения вопроса (иконка с точкой) или нет (иконка без точки).

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

![Пример комментария](/assets/images/features/chats/chats_1.png "Пример инвойса с комментарием в Гулливер ЦРМ")

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

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

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

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

![Раздел комментарии](/assets/images/features/chats/chats_3.png "Раздел комментарии в Гулливер ЦРМ")

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


Комментируй все


## Списки или зачем сегментировать клиентов

Сегментация клиентов — это разделение их на группы по определенным признакам или критериям: их геолокации, возрасту, потребностям, действиям на сайте и пр. Но как представить в нашем приложении сегментацию? Мы реализовали свой собственный инструмент и назвали его **Списки**.

Не знаю, как вы, а мы постоянно делаем списки. Списки на обзвон 📞, списки участвующих в мероприятии, списки для экскурсии 🎄, списки на подарки 🎁. Мы постоянно работаем со списками. Нам надо список клиентов, которые не ходят. Иногда нам нужен список, клиентов, которые не заплатили. И постоянно мы в поиске инструмента, который нам в этом помогает: просто Word, Excel или еще какой-нибудь. В них мы копируем информацию, теряем их, редактируем много раз, забываем сохранить...

А что если у нас будет инструмент с широкими возможностями кастомной фильтрации и сортировки, с возможностью совместного редактирования, прямо внутри системы, у которого в доступе уже есть все наши клиенты 🆒. Мы осознали необходимость этого инструмента не сразу. Но после разработки его прототипа, поняли, что это просто бомба 💣💣💣. **Списки** могут решать очень много проблем. Они настраиваются, они автоматизируются, в них есть предустановленные сущности в виде филиалов, ваших программ, пользователей и т.д.

![Списки в Гулливер ЦРМ](/assets/images/features/lists/lists_4.png "Списки в Гулливер ЦРМ")
Учитывая наши терзания по поводу [стандартизации и кастомизации](/blog/post/standardization-vs-customization "Стандартизация или кастомизация"), в каждом списке есть предустановленные колонки филиалов, программ, клиентов, пользователей. И в то же время вы можете создать любое кастомное свойство. Мощь этого инструмента крайне сложно описать в тексте, нужно быть поэтом. Однако, как только сделаешь первый список, понимаешь на сколько инструмент мощный. Мы уверены, что его потенциал будет описан не в одной статье.

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

### Основные функции

- **Все в одном месте** - объединяет функции сегментации клиентов, организации задач, заметок и комментариев в одном инструменте. Это позволяет легко находить нужную информацию и управлять своими задачами без необходимости переключаться между различными приложениями и инструментами.
- **Гибкость** - позволяет создавать и настраивать свои собственные рабочие списки, свойства (колонки), опции (содержание ячеек), что делает его одним из самых гибких инструментов.
- **Коллаборация** - позволяет легко работать в команде, совместно редактировать документы и обмениваться информацией. Это делает его идеальным инструментом для командной работы и многофилиальной сети.
- **Дизайн** - предлагает выбор шаблонов и инструментов для дизайна списков. Это позволяет создавать красивые и удобные рабочие пространства, которые могут быть адаптированы под любые нужды.
- **Мгновенный экспорт** - любой список с легкостью можно экспортировать в другой список, либо на его основе создать шаблон на будущее или сформировать готовую группу.
- **Автоматизация** - вы можете настроить автоматизацию добавления клиентов по какому-либо признаку автоматически. Gulliver AI Bot сам с определенной периодичностью будет контролировать чтобы все клиенты были в списке.

### В целом,

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

### Работа со списками

Видео фрагмент

### P.s. 🧩🏆

> Списки нужны для гибкой сегментации клиентов по различным признакам c богатыми возможностями автоматизации, фильтрации, сортировки и экспорта


Cегментация клиентов. Списки 🦄


## Сохраняйте и делитесь информацией

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

[Корпоративная вики](/features/wiki "Gulliver CRM -> Wiki") - это инструмент, который может значительно улучшить совместную работу внутри компании. Она позволяет сотрудникам быстро и легко обмениваться информацией, идеями и знаниями, что может существенно повысить эффективность работы и сократить время на выполнение задач.

![Вики в Гулливер ЦРМ](/assets/images/philosophy/philosophy_6.png "Вики в Гулливер ЦРМ")

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


Сохраняйте и делитесь информацией


## Принцип многослойного пирога

Иногда самые прекрасные ощущения ты испытываешь от просмотра фильма или от прочтения книги, когда после определенного промежутка времени, ты понимаешь: «Ничего себе, тут есть еще что-то, тут есть глубина, тут есть более глубокая задумка». Ее сразу не видно, ее начинаешь понимать со временем. Особое восхищение появляется, когда понимаешь, что автор это заложил в произведение осознанно. Почему же мастера так делают, не выкладывают все на поверхность, не доносят простым языком?

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

Этот принцип на сколько у нас хватило знаний и таланта, мы попытались перенести в нашу систему. Мы попытались максимально простое и часто используемое в работе оставить на поверхности, а редко используемое и сложное скрыть в глубине системы. Создавать такие взаимоотношения в строгой системе – это целое искусство, и я не уверен, что мы преуспели, но мы хотя бы попытались… Это позволяет пользователям максимально гладко осваивать основной функционал, и узнавать что-то новое о системе в размеренном темпе, без стресса и негативной эмоциональной окраски.

![Принцип многослойного пирога](/assets/images/philosophy/philosophy_2.png "Принцип многослойного пирога")

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


Принцип многослойного пирога


## Стандартизация или кастомизация

Системы автоматизации можно разделить на две большие группы. Первая группа с жесткой стандартизированной структурой сущностей, в которых невозможно добавить или убавить функции (Bitrix24) и кастомизируемые, где функции и сущности вы можете создавать самостоятельно (Fibery). Гибкие настраиваемые системы позволяют адаптироваться под изменяющиеся обстоятельства. Для систем с жесткой структурой это очень проблематично, если не невозможно.

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

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

![Списки в Гулливер ЦРМ](/assets/images/philosophy/philosophy_4.png "Списки в Гулливер ЦРМ")

Если вам чего-то не хватает в системе, вы можете создать свой инструмент на основе списков, автоматизировать его и сохранить на будущее в виде шаблона. [Списки](/features/lists "Gulliver CRM -> Lists")


Стандартизация или кастомизация


Мы начинаем, альфа тест. До этого этапа мы провели теоретическую работу с бизнес анализом, проектированием системы, написания подготовительной документации. Сформировали ряд диаграмм, которые позволяют оперативно обновлять предметную область в голове разработчиков. Провели тестирование MVP. И наконец добрались до тестирования в поле 🎉.

### Что сделали:

- Поняли, что управленческий учет в этой области требует гибкого контроля за финансами 💡
- спроектировали и написали первый прототип биллинга 💰
- написали множественную филиальность 🏡🏠
- написали стандартный функционал (регистрация, аутентификация и т.д.)
- переписали журнал на другом инструменте (ag-grid, о этого использовали devexpress)

### Основная цель альфа тестирования.

Очень интересно, каким образом на приложение реагируют реальные клиенты, нужен ли наш продукт на рынке. Для альфа тестирования мы выбрали [Детский клуб Гулливер](https://www.gulliverclub.com/ "gulliverclub.com").

Гулливер выбрали по нескольким причинам:

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

На момент альфа тестирования приложение кроме общих подсистем (регистрация, аутентификация и т.д.) содержит два больших компонента: журнал и биллинг.

При тесте мы попытаемся найти как можно больше явных/грубых/критических багов (например, которые приводят к падению приложения), до того, как приложение будет готово к следующему этапу тестирования и более широкому кругу пользователей. Повторно удостовериться, что наш продукт нужен на рынке...

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

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

Наравне с оценкой работоспособности проводим множественное тестирование готовых юс-кейсов на предмет любых ошибок.
Обращаем внимание на:

1.  Не работает
2.  Не удобно
3.  Не красиво
4.  Не понятно
5.  Не хватает (что хочу, а его нет или круто было бы)

### Технологический стек

Несколько изменений:

- Начали интеграцию Typescript
- Внедрили Redux и Redux Thunk
- Добавили Reselect и селекторы
- Перешли на MaterialUI

### P.s. 🧩😕

- Названия снова нет (но мы держимся 😁😂)
- Почти полностью переписали код оО
- В команде 3 человека (🐱💻🐱👓🐱🚀)
- Два рабочих компонента - Журнал и Биллинг


Альфа тестирование


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

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

![Примерная схема биллинга](/assets/images/features/billing/billing_1.png "Примерная схема биллинг в Гулливер ЦРМ")

### Баланс 🔮

Система биллинга очень похожа по работе на биллинг операторов сотовой связи. В центре системы находится **баланс** клиента. Мы его пополняем платежами, которые можно вносить разными способами (через банк, кассу, ЕРИП, другие системы оплаты). Затем, с баланса клиента происходит списание средств на различные услуги: смс, звонки интернет. В распечатке в конце месяца мы можем узнать, какое количество звонков, смс мы сделали, и сколько каждая из услуг стоила. Каждая из услуг отдельно списывает с баланса необходимую сумму.

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

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

#### Баланс может быть увеличен:

- **Платежами** (payment) (наличные, банковский, ерип, и т.д.). В теории это может быть большой один платеж, тысяча маленьких, отдельный платеж на каждую программу, по которой занимается клиент. Все платежи увеличат баланс на сумму платежа.
- **Переводом** (transfer) от другого клиента.

#### Баланс может быть уменьшен:

- **Списаниями** (charge) с баланса клиента для закрытия инвойса (invoice);
- **Возвратом** денег клиенту через кассу (refund);
- **Переводом** другому клиенту (transfer);

### Инвойсы 🎓

Второй краеугольный камень системы - **Инвойсы**.

Эквивалентом предоставленной услуги (абонемент программы, 4 индивидуальных урока у логопеда и т.д.) в нашей системы является инвойс (счет-фактура), точнее закрытый инвойс. На каждую программу ежемесячно необходимо выставлять инвойс. Система это делает автоматически 25 числа ежемесячно на следующий учебный месяц. Если инвойс отсутствует, его необходимо выставить самостоятельно. Таким образом человеку, который посещает 3 программы, ежемесячно должны выставляться 3 инвойса по цене соответствующих программ. (см. раздел Инвойсы). Однако инвойсы выставляются в открытом виде.

После того, как у клиента появляются инвойсы, система ежедневно пытается их закрыть. Закрыть инвойс возможно только при достаточности денег на балансе. Если денег недостаточно, это свидетельствует о необходимости увеличить баланс клиента платежами или платежом. Таким образом баланс клиента — это сундук, который клиент должен пополнять, чтобы в последующем оттуда доставать деньги для получения услуг.

### Пример из жизни 🤦‍♂️

Иванов Василий ходит на шахматы и английский. 25 числа на следующий месяц ему автоматически выставятся 2 инвойса по ценам месячных абонементов этих программ. Примерно: инвойс №1 на шахматы - 80 руб., №2 английский - 100 руб. Итого 180 рублей. Для закрытия этих инвойсов он должен пополнить баланс на 180 рублей. Однако пополнение не зависит от нас. Он может пополнить на 500, что больше необходимого, при этом все инвойсы закроются и на балансе останется 320 рублей на следующий месяц, он может оплатить 180 рублей и все инвойсы закроются и на балансе будет 0. Или платить ежедневно по 5 рублей 32 платежа (ну так хочет он) 🤪. В этом случае система будет ежедневно пытаться закрывать инвойсы, на которые хватит денег: сначала, когда денег хватит, закроется самый дешевый на 80 рублей, потом на 100 рублей и т.д., однако пока инвойс не закрыт, разница между балансом и суммой выставленных инвойсов будет отображаться у клиента.

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

### Важно 📢

Не зависимо в какие филиалы, на какие программы ходит наш клиент, у него один баланс.

### Ошибки и их решение

Мы все делаем ошибки 🐞 и это нормально. Такие ошибки появляются достаточно редко, но они случаются... Мы предусмотрели вероятность человеческих ошибок на всех этапах, поэтому в систему заложены механизмы решения таких проблем.

1.  Неверный платеж - если платеж меньше необходимого, внесите недостающую сумму еще одним платежом; если платеж больше необходимого сделайте возврат
2.  Неверный возврат - если возврат меньше необходимого, верните недостающую сумму еще одним возвратом; если возврат больше необходимого сделайте платеж
3.  Неверный перевод - сделайте обратный перевод;
4.  Неверная сумма открытого инвойса - отмените инвойс и выставьте новый инвойс на правильную сумму.
5.  Неверная сумма закрытого инвойса. Закрытый инвойс свидетельствует, что произошло списание, а значит баланс клиента уменьшился на сумму инвойса. Просто отменить инвойс в таком случае не получится, и система не позволит это сделать. Однако отменить его все же можно. Это могут делать пользователи с высоким уровнем доступа, при этом сформируется новый корректирующий документ, который называется **коррекцией**, при этом произойдет возврат денежных средств на баланс клиента на сумму инвойса. После этого нужно выставить новый инвойс на верную сумму и закрыть его с баланса.

### P.s. 🧩🏆

> Биллинг нужен для учета финансовых взаимоотношений с клиентом, он организован на основе формирования различных финансовых документов, связанных между собой.


Биллинг


## Группа как центр системы

##### (updated: 01.03.2023)

В каждом бизнесе тысячи нюансов и мелочей. Самым важной отличительной особенностью ваших процессов является групповой характер проведения занятий, а именно ведение занятий в группах. Поскольку занятия ведутся в группах мы считаем, что самым важным показателем, обладающий максимальной управленческой пользой является **наполняемость группы клиентами.** Более того именно его нужно максимально оперативно отслеживать, и вот почему.

![Alt text](/assets/images/philosophy/philosophy_1.png "Журнал Гулливер ЦРМ")
У вас может быть 100 клиентов в 10 группах, при этом вы хорошо зарабатываете или 100 клиентов в 100 группах, и вы получаете убыток. В обоих случаях вы получаете одинаковый доход. Разница в этих случаях заключается в оплате труда сотрудников. Во втором случае оплата сотрудникам будет в 10 раз больше и это съест всю вашу выручку, и вы не получите прибыль. Давайте сделаем меньше больших групп! Но! Очень большие группы делать тоже нельзя, это не нравится клиентам, сотрудникам, их сложнее вести, может не позволять помещение, да и качество услуги будет так себе и т.д. Поэтому перед управляющими должна стоять задача поддерживать максимально возможную наполняемость группы, которую вам позволяют обстоятельства.

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

Это понимание легло в основу архитектуры нашей системы. Мы реализовали не только классический функционал CRM системы, ядром которого является сам клиент и его персональные отношения с бизнесом, мы переосмыслили и во главу угла системы поставили самый важный процесс – удобный менеджмент групп с возможностью оперативно и в доступной форме получать информацию о состоянии дел в группе и вовремя реагировать.

Сами данные это прекрасно, но не менее важной составляющей является их представление для пользователя. Мы искали эту форму и нашли в виде журнала.

Журнал – является краеугольным камнем нашей системы 🌞. Для его рождения пришлось переосмыслить групповой учет. Для людей, которые занимаются управлением, очень важно своевременно получать информацию. Журнал позволяет оперативно видеть состояние дел в группе, это достигается **цветовой визуализацией** 🌈. Мы исходим из предпосылки, что каждое занятие, которое запланировано, должно быть посещено клиентом. Такое посещение отмечается зеленым цветом. Если клиент пропускает занятие, мы его отмечаем красным цветом. Однако пропуск может быть по уважительной причине, например, болезнь клиента. Такое состояние отмечается желтым цветом. Оно дает право этому клиенту отработать это занятие со своей или с другой группой в течение определенного промежутка времени. При этом отработанное занятие отмечается фиолетовым цветом. Вот и все. Механику с больничным можно не использовать и зависит от ваших бизнес процессов и предпочтений. Однако в таких сферах как дошкольные центры развития дети часто болеют, и многие клиенты считают не справедливым, если их занятия просто сгорят. Вариант с учетом отработок является компромиссом.

Есть еще один важный момент 👆. Голубые ячейки - это **планируемые** занятия. Поскольку с журналом работает много людей, каждый может вносить информацию, и для примера, администратор может внести нового клиента в систему и назначить ему первое пробное планируемое занятие. Или сам педагог, чтобы не забыть, клиентов, которые хотят прийти на занятие отмечает голубым цветом, в дальнейшем голубой цвет можно поменять на любой другой или удалить.

Все **активные** клиенты выделяются ярким цветом, клиенты, которые перестали ходить, имеют бледный оттенок и расположены в конце списка. Слева в списке клиентов, мы видим необходимую информацию о возрасте (важно для детских центров из-за возрастных различий детей), их контактные данные (удалены на фото), клиентский баланс и др. Таким образом любой сотрудник, который работает с журналом, видит, что занятия оплачены или не оплачены на данный момент и нужно напомнить клиенту об оплате 👨🏫.
![Хороший журнал](/assets/images/features/journal/journal_1.png "Хороший журнал")
Это пример хорошего журнала 👌, в нем мы видим, что люди ходят отлично (практически все зеленое), что в группе нет места, вы получаете максимальный доход. Во втором случае сразу видно, что люди покидают группу (все красное), и скоро станет вопрос о ее расформировании 😢. Таким образом визуализация посещений с использованием разных цветов дает интуитивное понимание о состоянии дел в группе.
![Плохой журнал](/assets/images/features/journal/journal_2.png "Плохой журнал")
Еще мы видим на втором журнале большое количество привязанных комментариев 💬. Это значит администратор предпринимает усилия по спасению группы, обзванивает клиентов, и сохраняет информацию о результатах взаимодействия с клиентами. При этом комментарии привязываются к разным сущностям: клиентам, ячейкам посещения, урокам, самой группе. По этой привязке понятно, что комментирует пользователь. Все эти комментарии, позволяют не просто понять, что с клиентом, а понять обстоятельства написания комментария, связанные сущности, требует ли вопрос решения, или это просто информация для запоминания.

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

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

### Какую информацию содержит

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

### Что позволяет делать:

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

### Работа в группе

Видео фрагмент

### P.s. 🧩🏆

> Журнал нужен для оперативного управления группами на основе информации о посещениях, учителях, клиентах и т.д.


Группа как центр системы


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

### Что уже сделали:

- провели подготовительную теоретическую работу: нашли пару идей 💡, которые не реализованы на рынке;
- провели бизнес анализ домена 🔮;
- сделали теоретическое проектирование системы 📌.
- посмотрели, кто есть на рынке и что предлагают конкуренты. Увидели, что идеи, которые мы хотим заложить в продукт, у конкурентов не реализованы 🧨🎇.
- написали подготовительную документацию, техническое задание 👨💻.
- сформировали ряд диаграмм, которые позволяют оперативно обновлять предметную область в голове разработчиков 🧷.
- написали прототип, чтобы можно было покликать 🐭
- провели тест mvp 🧲

### Подробнее

Теоретическая подготовка и проектирование включает разработку технической документации, включая рад диаграмм, позволяющих разработчикам лучше представлять предметную область.
Первая диаграмма представляет собой структуру сущностей предметной области и их взаимоотношений **(ERD)**. Диаграмма не очень грамотно оформлена, но свою работу делает.

![Примерная структура сущностей Гулливер ЦРМ](/assets/images/blog/er.jpeg "Примерная структура сущностей Гулливер ЦРМ")

Одной структуры сущностей недостаточно для начала разработки. После этого мы сделали диаграмму вариантов использования **(use-case diagram, UCD)**. Эти диаграммы мы выполнили в обычном онлайн редакторе диаграмм **app.diagrams.net**.

![UCD в Гулливер ЦРМ](/assets/images/blog/use-case.png "UCD в Гулливер ЦРМ")

Структурирование предметной области очень важный элемент разработки программного продукта. UCD диаграмма описывает границы системы, определяет точки взаимодействия с системой, а также перечисляет основных акторов (действующих лиц), которые будут взаимодействовать с системой, дает представление об объеме взаимодействия с системой и дает названия этим взаимодействиям. Очень полезно, в качестве справочного материала, к которому постоянно возвращаешься в процессе разработки.

В дальнейшем в приложении **websequencediagrams.com**, каждый вариант использования (use-case) был описан в виде диаграммы последовательности действий **(Sequence diagram, SD)**. Диаграммы последовательности используются для уточнения диаграммы вариантов использования для более детального описания логики. Отличное средство документирования проекта с точки зрения сценариев использования!

В общей сложности, в подготовительном этапе у нас получилось 26 готовых документов. В принципе, этих диаграмм было достаточно чтобы начать проектирование интерфейсов, которое мы делали в Axure RP с применением готовых наборов элементов интерфейса. Первые интерфейсы выглядят довольно примитивно. Это нормально.

![Layout Гулливер ЦРМ](/assets/images/blog/first-ui-proto.jpg "Layout Гулливер ЦРМ")

Для первичной верстки достаточно. Чтобы хоть как-то прикинуть объем предполагаемой технической работы мы написали **Техническое задание**, опубликовать я его конечно не могу. Но могу сказать, что вышел достаточно увесистый труд на несколько сотен страниц. На этом этапе у нас в команде было 2 разработчика 🚣‍♂️ 😍.

Вот так примерно выглядит первый прототип журнала в Axure RP.
![Прототип Журнала](/assets/images/blog/theory_1.png "Прототип Журнала")

### Технологический стек

Для реализации этого проекта мы выбрали наиболее развевающийся **JS-стек MERN (mongoDB, Express, React, Node.js)**. Сам по себе стек идеально подходит:

- для прототипирования
- обладает огромным комьюнити
- на него легко найти разработчиков
- сам по себе очень быстро работает
- не требует лицензионных отчисления
- моноязычный

Отдельные компоненты тоже обладают рядом преимуществ.

#### MongoDb

MongoDB — это база данных NoSQL, которая ориентирована на использование документов и коллекций в отличие от использования строк и таблиц, как в стандартных базах данных. Базовой единицей данных в документах является пара ключ-значение. Принято выделять следующие достоинства:

- MongoDB использует JavaScript, что является самым большим преимуществом для стека MERN.
- Гибкие схемы документов. Модель документа MongoDB позволяет легко моделировать и манипулировать практически любой структурой данных
- Скорость. База данных легко индексирует документы, следовательно, дает более быстрый ответ серверу.
- Доступ к данным без кода. MongoDB хранит и представляет данные в формате документа. Это означает, что что можно получить к ним доступ с помощью родных структур данных для любого языка. Например, ассоциативные массивы в JavaScript.
- Данные хранятся в виде JSON. Синтаксис JSON очень прост и поддерживается практически любыми браузерами.

#### Express.js

Express — это фреймворк, созданный на базе платформы NodeJs. Его преимущества значительно упростят и укоротят внутренний код. В стеке Express играет немаловажную роль, так как с его помощью настраивается маршрутизация и создается API-сервер для взаимодействия между клиентской и серверной частью приложения. У технологии есть ряд преимуществ:

- Позволяет легко и быстро разрабатывать веб-приложение Node.js.
- Простой и легкий в настройке.
- Он позволяет определять маршруты приложения на основе методов HTTP и URL-адресов.
- Легко обрабатывает статические файлы и службы приложения.
- Позволяет создать сервер с REST API.
- Быстрое подключение к базам данных.

#### React.js

React — это самая популярная библиотека JavaScript. С помощью React можно разработать быстрый и стабильный пользовательский интерфейс. Больше достоинств:

- Легкий в обучении и использовании. React обладает хорошей документацией, а благодаря широкому сообществу имеется большое количество обучающих руководств, курсов и ресурсов.
- Высокая производительность — такие функции, как Virtual DOM, JSX и компоненты, делают его намного быстрее, чем остальные фреймворки.
- Компоненты для многократного использования. Каждый компонент имеет свою собственную логику и управляет собственным рендерингом. Поэтому его можно повторно использовать там, где нужно. Повторное использование кода помогает упростить разработку и поддержку приложения.

#### Node.js

Node.js — среда выполнения, позволяющая запускать код JavaScript на сервере, благодаря чему фронтенд-разработчик может создавать легко интегрируемые приложения. В отличие от других популярных серверных технологий:

- Основан на JavaScript, что позволяет использовать один язык программирования на всем проекте.
- Предлагает высокую производительность для приложений реального времени.
- Масштабируемость. С точки зрения разработки Node.js позволяет использовать микросервисы, которые в дальнейшем позволяют разделить приложение на более мелкие части.
- Быстрое выполнение кода.

### MVP

После реализации основного объема кода мы провели тестирование MVP, и он показал неплохой фидбэк. Нашей отличительной идеей является журнал. И идея с журналом оказалась рабочей, такой подход хорошо ложиться на бизнес-процессы и мышление сотрудников, и мы планируем ее развивать. Если удастся, мы хотим сделать журнал группы основным компонентом системы, из которого можно выполнять большинство процессов.

### P.s. 🧩😕

- Названия нет (но мы держимся 😁😂)
- В команде 2 человека (достаточно, чтобы обсуждать и писать 🐱👤, парное программирование оно такое)
- Один рабочий компонент - Журнал 📚


Блог

Веселитесь 🎉😁😆

Лена Леонова

Статьи

Передавайте чувства и эмоции 😁, даже когда невозможно увидеть человека и его выражение лица 😝

Веселитесь 🎉😁😆

Возможно, вас также заинтересует:

Обновления

Рассылки 💌

Обновления

Задачи❤️‍🔥

Статьи

KISS😘 и Заумь

Обновления

Кабинет клиента

Все еще есть вопросы?