Атлас
Клиентский портал производственной компании — заказы, спецификации, документы и статусы отгрузок вместо почты и звонков.
Сайты и веб-платформы · Интеграции и данные
Сроки3–5 месяцев до запуска пилота — ориентир, уточняется после обследования
01 / 06
Платформа продаёт и обслуживает без ручной работы
Для компаний, у которых сайт стал рабочим инструментом продаж и сервиса, а не витриной. Заявки теряются между почтой и таблицами, клиенты звонят за информацией, которую могли бы увидеть сами, а оптовые заказы оформляются вручную. Проектируем платформу от бизнес-логики и данных: каталог, кабинет и заказы связаны с CRM и учётной системой, поэтому продажи идут без двойного ввода.
С какими ситуациями приходят
- Заявки с сайта приходят на почту и теряются между отделами
- Клиенты звонят менеджеру за статусом заказа, потому что увидеть его негде
- Оптовые заказы оформляются вручную: прайсы, письма, перезвоны
- Сайт не отражает масштаб компании и проигрывает в сравнении с конкурентами
- Продукт вырос из прототипа и перестал выдерживать нагрузку
- Данные о клиентах и заказах разбросаны по таблицам и перепискам
- Новый канал продаж не запустить: сайт не связан с учётом
Что создаём
- Корпоративные сайты и порталы
- Личные кабинеты и клиентские сервисы
- B2B-платформы и дилерские порталы
- Интернет-магазины и маркетплейсы
- SaaS-продукты
- Внутренние веб-инструменты для команд
Что входит в работы
- Личный кабинет с ролевым доступом
- Каталог с поиском, фильтрами и персональными ценами
- Онлайн-оплата и подписки
- Обмен заказами и остатками с CRM, ERP и 1С
- Статусы заказов и документы онлайн
- API для партнёров и мобильных приложений
- Уведомления в почте и мессенджерах
- Аналитика воронки и поведения на сайте
- Работа в нескольких регионах и на нескольких языках
Как устроено решение
Решение состоит из трёх частей: ядро с бизнес-логикой и данными, интерфейсы для клиентов и сотрудников, слой обмена с внутренними системами. Ядро отделено от интерфейсов, поэтому один продукт обслуживает и сайт, и личный кабинет, и мобильное приложение — новый канал продаж не требует второй разработки. Обмен с CRM, ERP и 1С идёт через API и очередь событий: если смежная система недоступна, заказ не пропадает, а дожидается её возвращения. Масштаб выбираем под задачу — компактное ядро там, где важна скорость запуска, отдельные сервисы там, где нагрузка растёт неравномерно.
Слои решения
frontend
TypeScript · React · Next.js
backend
Node.js · Python
data и хранилища
PostgreSQL · Redis · Kafka
infrastructure и devops
Docker · Kubernetes
Интеграции
1С
- 1С:Предприятие
crm
- CRM по API
erp и учётные системы
- ERP заказчика
- управление заказами
платежи и банки
- платёжные сервисы
- эквайринг
мессенджеры
- мессенджеры
- чат на сайте
- уведомления клиентам
логистика
- логистические сервисы
- трек-номера и статусы доставки
api и обмен данными
- REST API
- вебхуки и обратные вызовы
Как работаем
Обследование
Разбираем, как компания продаёт и обслуживает сейчас, какие системы в этом участвуют и где теряются заявки. На выходе — перечень сценариев, требования к данным и список систем для обмена.
Проектирование
Собираем сценарии пользователей, прототипы экранов и модель данных, согласуем архитектуру и состав интеграций. По этому описанию оценивается объём разработки и фиксируется порядок этапов.
Разработка
Строим платформу итерациями: каждая заканчивается работающим блоком, который можно открыть и проверить на своих данных. Прогресс видно на регулярных демонстрациях, а не в финальной презентации.
Тестирование и запуск
Разворачиваем платформу на боевой площадке, переносим контент и данные, подключаем наблюдение. До открытия доступа проверяем права, поведение под нагрузкой и защиту персональных данных.
Внедрение и обучение
Обучаем по ролям: редакторов — работе с контентом и каталогом, менеджеров — обработке заказов, администратора — правам и настройкам. Первые недели работаем рядом и правим то, что мешает в реальной эксплуатации.
Развитие
Снимаем метрики использования, собираем обратную связь клиентов и ведём очередь доработок. Приоритеты следующих версий определяют данные, а не список пожеланий с начала проекта.
Что получает компания
- Работающая платформа на вашей инфраструктуре или в вашем облаке
- Исходный код и исключительные права на него
- Описание архитектуры, модели данных и интеграций
- Настроенные среды разработки, тестирования и боевой работы
- Инструкции для администраторов и редакторов, обученные сотрудники
- Подключённая аналитика и план развития на ближайшие итерации
Качество и безопасность
Права разграничены по ролям: клиент видит свои заказы, менеджер — свой участок, администратор — настройки, а действия с данными остаются в журнале, поэтому спорную ситуацию разбирают по записям, а не по памяти сотрудников. Изменения выходят на боевую площадку только после автотестов и проверки на тестовом окружении — обновление каталога не роняет оформление заказа. Обмен с учётной системой рассчитан на её недоступность, а нагрузку и защиту персональных данных проверяем до запуска, а не после первой распродажи.
Команда проекта
- Руководитель проекта
- Продуктовый аналитик
- Архитектор решения
- Дизайнер интерфейсов
- Разработчики backend и frontend
- Инженер по тестированию
Как это работает у нас
Говорим на языке бизнеса
Задачу платформы формулируем в деньгах и сроках: сколько заказов оформляется вручную, где теряются заявки, что мешает открыть новый канал продаж. Экраны и интеграции появляются в проекте как ответ на эти вопросы, а не как список пожеланий к сайту.
Проект ведёт основатель
Основатель разбирает задачу на первой встрече и сам принимает спорные решения: что входит в первый запуск, чем платформа обменивается с учётом, где остановиться и выйти к пользователям. Согласование не ходит между отделами подрядчика.
Внедряем, обучаем, поддерживаем
Передаём не архив с кодом, а работающие продажи: редакторы наполняют каталог, менеджеры обрабатывают заказы, администратор управляет правами. После запуска доработки идут по метрикам использования.
Проектные сценарии
Дилерский портал вместо заявок по почте
Дистрибьютор принимает оптовые заказы почтой и по телефону. Менеджеры вручную сверяют остатки, персональные цены и лимиты, из-за чего заказы уходят с ошибками, а ответ клиенту откладывается.
Строим портал с каталогом, персональными ценами и лимитами по каждому контрагенту. Остатки, заказы и взаиморасчёты синхронизируются с учётной системой, статус заказа виден в кабинете без звонка менеджеру. Менеджеры переключаются с оформления на работу с ключевыми клиентами.
Кабинет клиента сети сервисных центров
Клиенты записываются по телефону, историю обслуживания получают на бумаге, а администраторы заняты звонками о статусе работ. Часть записей теряется в часы загрузки.
Проектируем кабинет клиента: запись с выбором филиала, статус текущего ремонта, история обслуживания и оплата. Кабинет связан с учётной системой сервиса, поэтому расписание совпадает с рабочим, а напоминания о плановом обслуживании уходят сами.
Продукт перерос собственный прототип
Онлайн-сервис вырос из быстрого прототипа: пользователей стало больше, система замедляется под нагрузкой, каждая новая функция задевает старые. Остановить сервис на переделку нельзя — клиенты платят за доступ каждый день.
Начинаем с обследования кода и архитектуры, находим узкие места и составляем план поэтапной перестройки. Критичные части выносим в отдельные сервисы, добавляем автотесты и наблюдение, переводим выкладку на автоматический конвейер. Сервис работает и продаётся всё время перестройки.
Типовые решения
Рельеф
Собственная витрина D2C-бренда — каталог, подборки и оформление заказа рядом с товарным учётом и доставкой.
Сайты и веб-платформы
Сроки2–4 месяца до первого релиза витрины — ориентир, уточняется после обследования
Вопросы и ответы
От чего зависит стоимость платформы?
От числа ролей и сценариев, глубины обмена с внутренними системами, требований к нагрузке и готовности контента и данных. Отдельная статья — состояние систем, с которыми предстоит обмениваться: наличие API сокращает работу, закрытые продукты требуют обходных путей. Стоимость по этапам называем после обследования и проектирования, когда состав работ зафиксирован.
Сколько идёт проект?
Срок складывается из этапов: обследование, проектирование, разработка итерациями, тестирование и запуск, внедрение и обучение, развитие. Ориентир по срокам даём после проектирования, когда сценарии и архитектура согласованы. Сильнее всего на длительность влияют объём интеграций и скорость согласований на вашей стороне.
Готовая платформа или разработка под себя?
Зависит от того, что на платформе держится. Управляемый сайт с контентом дешевле и быстрее собрать на готовой системе с доработками. Если платформа обслуживает заказы, персональные цены и права клиентов и обменивается с учётом, коробку пришлось бы ломать под себя — собственное решение выходит дешевле в поддержке.
Как платформа свяжется с 1С и другими системами?
Обмен проектируем на старте: разбираем, какие данные живут в 1С, CRM и на складе и какая система считается источником истины по каждой сущности. Данные ходят через API и очередь событий, поэтому вводятся один раз и не расходятся между системами. Если готового API нет, подключаемся через выгрузки или внешний переходник, не переделывая саму систему.
Кому принадлежат код и данные?
Компании-заказчику. Исходный код передаётся вместе с исключительными правами, репозиторий и площадка оформляются на вашу компанию. Данные клиентов и заказов хранятся на вашей инфраструктуре или в вашем облачном аккаунте, поэтому смена подрядчика не превращается в переезд.
Кто ведёт платформу после запуска?
Та же команда, которая её строила: наблюдение, обновления, разбор обращений по согласованному регламенту и развитие по очереди доработок. Если у вас есть своя разработка, передаём код, документацию и доступы и помогаем на этапе передачи. Сопровождение оформляется отдельным направлением с понятным составом работ.
Обсудить задачу
Опишите задачу и текущий контур — вернёмся с разбором: что входит в работу, в каком порядке и от чего зависит срок.
Первая встреча и разбор задачи — с основателем компании.