Когда майнинг-хостинг растёт, рано или поздно встаёт вопрос - как организовать учёт клиентов, оборудования и платежей. Самый очевидный путь в этот момент - взять обычную CRM с рынка. Мы тоже пошли по этому пути. И через несколько месяцев попыток адаптации универсальных CRM под нашу специфику пришли к выводу, что задача у майнинг-хостинга совсем не CRM-ная. Поделимся своим опытом и расскажем, почему в итоге перешли на операционную систему вместо CRM.
С чего у нас всё начиналось - учёт в Excel
Когда хостинг только запускается, первая система учёта - почти всегда Excel, и у нас было так же. Имена клиентов, контакты, модели асиков, серийные номера, тарифы, даты ввода оборудования, платежи - всё лежало в одной-двух таблицах. Пока клиентов мало, эта схема работает: открыл таблицу, посмотрел, обновил.
Проблемы появились, когда мы начали расти. На 10-15 клиентах таблица уже «жила своей жизнью»: разные сотрудники по-разному заполняли поля, форматы дат расходились, появились дубликаты. На 30 клиентах Excel стал источником постоянных ошибок - где-то опечатка в серийнике, где-то расхождение в тарифе, где-то менеджер забыл обновить статус оборудования.
Почему мы решили уйти с Excel
В какой-то момент мы посчитали, сколько времени команда тратит на ручной учёт. Получилось много. И это были не разовые задачи, а регулярная нагрузка:
- Дублирование одних и тех же данных в разных файлах
- Невозможно посмотреть историю: кто, когда, какое поле менял
- При увольнении сотрудника терялась логика, которая была у него в голове, и доступ к его файлам
- Каждое начисление за электричество - ручной расчёт с риском ошибок
- Клиенты регулярно звонили проверить «работает ли мой асик», и каждый ответ - несколько минут поиска
- После введения реестра ФНС в 2024 подача отчётности стала отдельной задачей на дни
Не одна большая проблема, а накопление мелких - каждое из которых съедает рабочее время команды. И с ростом клиентов нагрузка росла линейно.
Первая мысль - взять универсальную CRM
Логичный шаг в такой ситуации - посмотреть в сторону CRM. На рынке десятки систем, есть бесплатные тарифы для старта, документация подробная, специалистов по внедрению - много. Мы изучили несколько вариантов универсальных CRM и в одной даже стартовали внедрение.
Эти системы прекрасно решают задачи, под которые сделаны: ведение продаж, воронка сделок, контактная база, рассылки, отчёты по выручке, постановка задач сотрудникам. Это сильные продукты с большой пользовательской базой, и для своих ниш - отличный выбор.
Мы шли с понятным запросом: «нам нужна CRM для учёта наших клиентов». Логика казалась простой - клиенты есть у любого бизнеса, инструменты для работы с клиентами есть на рынке, надо просто выбрать подходящий. В процессе адаптации стандартной CRM под нашу специфику быстро стало понятно, что мы изначально неправильно сформулировали задачу.
Что универсальные CRM не закрывают в майнинг-хостинге
Конкретные пробелы, на которые мы натолкнулись:
1. У нас в учёте не «сделки», а оборудование с историей. В обычной CRM основной объект - клиент или сделка. У нас основной объект - конкретный асик с серийным номером, моделью, локацией в контейнере, потреблением, историей перемещений и сменой владельцев. Этого объекта в стандартной CRM нет, его приходится «прикручивать» через кастомные поля. На 100+ устройствах кастомные поля становятся не учётом, а его подобием.
2. Нет понятия «контейнер» и «полка». Майнинг-хостинг физически устроен по-другому: контейнеры, ряды, конкретные места размещения. Универсальной CRM не нужно знать, на какой полке стоит сделка. Нам нужно - иначе инженер не найдёт оборудование клиента, когда придёт его обслуживать.
3. Биллинг под электричество - не воронка продаж. В стандартной CRM выручка считается через сделки и оплаты. У нас начисление идёт по тарифу × потребление × период размещения, плюс плата за обслуживание, плюс сезонные коэффициенты. Это другая модель расчёта, и под неё обычная CRM не заточена.
4. Личный кабинет клиента нужен с другим содержанием. В обычной CRM ЛК клиента - это интерфейс для просмотра заказов и счетов. У нас клиенту нужен онлайн-статус каждого его асика, история работы, текущее потребление, выгрузка отчётов в ФНС за свой период. Стандартного модуля под это нет - нужно либо разрабатывать самостоятельно, либо использовать сторонний интерфейс.
5. Специфика регуляторной отчётности. Универсальная CRM ничего не знает про реестр операторов майнинговой инфраструктуры. XML-отчёт по схеме ФНС не входит в стандартный функционал ни одной такой системы. Каждый отчётный период данные приходится собирать вручную, хотя они могли бы быть внутри системы.
Если посмотреть на эти пять пунктов вместе - становится виден главный вывод. Это не задачи для CRM. CRM - про работу с клиентами и сделками. Нам нужно учитывать оборудование, считать биллинг по электричеству, фиксировать инциденты, давать клиенту полноценный личный кабинет с онлайн-данными, готовить регуляторную отчётность. Это уже не CRM. Это другой класс системы - операционная система хостинга.
Что мы пробовали выжать из универсальной CRM
Прежде чем сформулировать этот вывод, мы попробовали несколько обходных путей:
- Заводили оборудование как «товары» или «активы» - на 30-50 единицах перестало хватать удобных представлений
- Создавали кастомные поля для серийников, моделей, локаций - система превратилась в нагромождение полей, которые никто из новых сотрудников не понимал без объяснений
- Пробовали интеграции для подтягивания данных с пулов - работало нестабильно, требовало постоянной поддержки разработчика
- В итоге появился параллельный учёт: CRM использовали для контактов и базовой информации, а реальное оборудование всё равно отслеживали в Excel-таблицах сбоку
Параллельный учёт в двух системах - это не решение, а новая проблема. Данные расходятся, сотрудники путаются, какой источник считать актуальным, а синхронизация съедает столько же времени, сколько мы сэкономили на автоматизации.
Что мы изменили: переход на операционную систему
Сформулировав, что нам нужна не CRM, а операционная система, мы стали смотреть в специализированные решения для майнинг-хостинга. Перешли на ROC - операционную платформу, которая изначально построена вокруг наших объектов учёта: клиент, оборудование, контейнер, потребление.
ROC - это не CRM и не специализированная CRM для майнинга. Это полноценная операционная система майнинг-хостинга. В одном контуре живёт учёт клиентов и их оборудования, биллинг электричества, инциденты и задачи команде, личный кабинет клиента, отчётность в ФНС, ролевой доступ для сотрудников, мультиплощадочная архитектура. CRM-задачи - карточка клиента, история взаимодействий - внутри этой системы тоже есть, но как один из модулей, а не как основа всего.
Внедрение заняло около трёх недель: миграция данных из Excel и старой CRM, обучение команды, настройка ролей и тарифов под нашу специфику. Не всё пошло гладко - часть данных пришлось чистить вручную, потому что в исходных источниках они были непоследовательными. Но это была разовая работа.
Что у нас изменилось после перехода
Чтобы наглядно показать разницу - что закрылось из тех пяти пунктов выше и что добавилось сверху:
1. Учёт клиентов. Карточка клиента с привязкой оборудования, договоров, платежей, обращений. Новый менеджер за пять минут видит всю историю работы с клиентом.
2. Учёт оборудования. Каждый асик в системе с серийником, моделью, локацией. Перемещения между контейнерами, смена владельца - всё с сохранением истории. Приём партии в 50 устройств идёт через сканер штрихкодов.
3. Биллинг под нашу модель. Расчёт начислений идёт автоматически по тарифу × потребление × период. Привязка к клиенту, договору, площадке - встроенная. Триггеры: например, sleep mode при долге.
4. Личный кабинет клиента. Веб- и мобильная версия с онлайн-статусом каждого асика, историей работы, текущими начислениями. Клиент сам формирует выгрузку отчёта по своему оборудованию - не звонит менеджеру.
5. Инциденты и задачи команде. Если что-то не так с оборудованием - автоматическая фиксация инцидента, назначение задачи инженеру, контроль времени реакции. Видно, кто из команды сколько закрывает.
6. Отчётность в ФНС. XML-отчёт собирается из тех же данных, что уже введены по ходу работы. За пять минут вместо нескольких рабочих дней.
7. Мультиплощадочность. Когда мы открыли вторую площадку, не пришлось разворачивать вторую систему. Контейнеры просто привязаны к разным локациям внутри единого контура.
Семь блоков задач. CRM-функции - только один из них. Остальное - это уже не про работу с клиентами в классическом смысле, а про операционку площадки целиком.
Почему это работает только в единой системе
Можно было бы попробовать собрать ту же функциональность из связки разных программ: CRM для клиентов, отдельная программа для биллинга, отдельный мониторинг оборудования, отдельный сервис для ЛК клиентов, отдельный конвертер для XML-отчётов. На бумаге звучит логично, но на практике такой связкой пользоваться тяжело - и вот почему.
Когда системы разные, данные приходится синхронизировать. Либо через интеграции, которые ломаются при любом обновлении одной из систем. Либо вручную - что съедает то время, которое мы хотели сэкономить.
Каждое изменение приходится вносить в несколько мест. Появился новый клиент - заведи его в CRM, в биллинге, в системе доступа в ЛК, в учёте оборудования. Переместился асик из одного контейнера в другой - отрази в учёте, в мониторинге, в ЛК клиента. Изменился тариф - пройдись по всем системам, где он используется.
Если данные где-то расходятся - начинаются споры с клиентами, ошибки в отчётах, потерянное время команды на разбирательства.
В единой системе одно изменение в одном месте автоматически отражается везде. Завели нового клиента - у него уже есть карточка, доступ в ЛК, привязка к биллингу, статус в отчётах. Это и есть разница между «CRM плюс ещё пять программ» и «операционная система хостинга».
Что осталось ручной работой
Чтобы картина не выглядела рекламной, важно проговорить ограничения.
Финальная проверка отчётов в ФНС перед подачей - за нашим бухгалтером. Цена ошибки в налоговой отчётности высокая, и этот час ручной работы автоматизировать нельзя. Сама подача в ФНС идёт через личный кабинет налогоплательщика - не часть нашей системы. Бухгалтерия и электронный документооборот пока живут в отдельных программах, прямой интеграции с ROC нет, и часть данных мы всё ещё переносим вручную или через выгрузки. И внедрение системы требует ресурсов: для хостинга на 5-10 клиентах переход экономически не оправдан, ручной учёт ещё дешевле.
Когда универсальной системы достаточно, а когда уже нет
Универсальной CRM (или просто Excel) может хватать, если на площадке до 10-15 клиентов, парк оборудования небольшой и однотипный, биллинг считается простыми формулами, а отчётность в ФНС вы пока не подаёте.
Пора смотреть в сторону специализированной операционной системы, если: клиентов больше 30-40, есть разные модели у одного клиента или несколько договоров, менеджеры регулярно собирают вручную «таблицу для отчёта», подготовка отчёта в ФНС стала отдельной задачей на дни. Если узнаёте у себя 2-3 пункта из второго списка - пора задуматься.
Итог: задача определяет инструмент
Универсальные CRM - отличные системы для тех задач, под которые они созданы. Если бизнес про продажи и сделки - это правильный выбор. Но майнинг-хостинг - это не про продажу клиенту услуги один раз. Это про долгосрочное обслуживание оборудования, регулярный биллинг, операционную работу команды и регуляторную отчётность. Это другой класс задач, и под него нужен другой класс инструмента - операционная система хостинга, а не CRM.
Мы пришли к этому выводу через несколько месяцев попыток адаптировать обычные системы под нашу специфику. Если у вас на площадке похожие вводные - наш опыт может сэкономить эти месяцы.
Если хотите увидеть, как ROC будет работать на вашей площадке - напишите команде в Telegram. Они проведут демо и ответят на все вопросы.
Функциональность платформы ROC может отличаться от описанной в статье - система развивается, набор возможностей меняется. Упомянутые универсальные CRM-системы - отличные продукты для задач, под которые они созданы.