Проблема
Переписка, файлы и производственные решения находятся в разных местах. Обычная CRM умеет хранить лид, но не моделирует технический путь от приложенной модели до готового к производству заказа.
Активный продукт · 2026
CRM для 3D-печати
Система, которая превращает разрозненные входящие заявки в подтвержденные менеджером производственные заказы.
Контекст
Программа строится вокруг рабочего процесса
Компания 3D-печати получает заявки по почте — часто с вложениями и неполными техническими данными. Менеджеру нужно проверить запрос, уточнить детали, решить, можно ли создать заказ, и сделать файлы и статус понятными всей команде.
Ограничение
Парсинг и анализ могут помогать менеджеру, но не должны незаметно принимать коммерческие или производственные решения. Нужны явные статусы, аудит и подтверждение человеком.
Роль и подход
Продуктовые решения и архитектура в одном цикле
Я описал путь заявки до заказа, определил роли и переходы статусов, спроектировал границы сервисов и реализовал Go-бэкенд с интеграциями. Интерфейс — целевое рабочее место менеджера, а не универсальная CRM.
Сначала процесс
Автомат состояний заказа — источник истины. Интеграции его питают, но не определяют.
Подтверждение человеком
Разбор входящего письма создает черновик. Заказ появляется только после явного действия менеджера.
Заменяемые адаптеры
Хранилище, почта и модель отделены от ядра, поэтому локальная среда и внешние сервисы используют один процесс.
Фоновые задачи
Передача файлов и анализ моделей идут асинхронно: со статусами и повторными попытками, без блокировки API.
Процесс
Автоматизация готовит данные — человек принимает решение
Входящее сообщение становится проверяемым черновиком. Распознанные поля и вложения сокращают ручной ввод, но ответственность за клиента, состав работ и создание заказа остается у менеджера.
- Получить письмо и вложения через входящий адаптер.
- Создать черновик; языковая модель при включении только предлагает значения полей.
- Дать менеджеру исправить данные, отклонить запрос или явно создать заказ.
- Хранить статусы, файлы, задачи хранилища и технический анализ в одной карточке.
Архитектура
Небольшое ядро и явные границы интеграций
Go API отвечает за аутентификацию, права, переходы заказов и аудит. PostgreSQL хранит состояние процесса. Воркеры выполняют медленные и ненадежные операции, а React-интерфейс работает с тем же API, что и операционные проверки.
Почему два языка? Go объединяет транзакционное приложение и адаптеры, а Python/trimesh дает зрелые инструменты геометрии за узким контрактом анализа.
Статус поставки
Что есть сейчас — и чего еще нет
Это активный продукт, а не отполированная ретроспектива. В августе 2026 года репозиторий был сверен с планом итераций; границы ниже проведены намеренно.
Основной рабочий процесс
JWT/RBAC, пользователи и клиенты; создание и статусы заказов; файлы и сменное хранилище; входящие черновики с подтверждением менеджера; фоновые задачи и аудит.
Технический файловый контур
Безопасная распаковка архивов, метрики STL, предупреждения о герметичности, превью и Three.js viewer есть в коде и тестах, но итерацию еще нужно принять на пилотном процессе.
Расчет стоимости
Типы печати, тарифы, экспресс- и детальный расчет, проверка готовности и данные технолога описаны в итерациях, но не выдаются за готовые функции.
Производственные операции
Задачи и Telegram-напоминания, история производства, управленческий дашборд, диагностика, резервное копирование и боевой деплой — будущая работа.
Компромиссы
Решения в пользу понятности и восстановления
- Черновик вместо автозаказа: на одно действие больше, но ошибка парсинга не превращается в обязательство.
- Асинхронный анализ: больше кода состояний задач, зато загрузки и API не зависают, а сбои можно повторить.
- Адаптер хранилища: дополнительная абстракция позволяет локально тестировать и менять внешний сервис без переписывания заказов.
- Пошаговая поставка: основной процесс можно проверить до расширения области ценами и производством.
Дальше
Сначала проверить, потом расширять
Следующая содержательная точка — пилотная приемка архивов, анализа STL и viewer на характерных файлах, затем уточнение правил расчета. Конверсия, экономия времени и производственные метрики намеренно помечены TBD, пока процесс не используется в работе.
Не показано: данные клиентов, доступ к репозиторию, учетные данные, реальные цены и непроверенные бизнес-метрики. Обложка и схемы синтетические.