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