Платформа продажного CRM — CRM на основі розмов з AI-звітністю та білінгом рішень

Огляд

Модульна CRM-платформа для продажів, побудована навколо розмов, а не статичних записів. Розмовний робочий простір (chat-first, дворівнева система статусів) — у центрі; модулі AI-звітності, збагачення лідів та організаційної аналітики надбудовуються над ним, усе під контролем детермінованого, незмінного білінг-леджера для ШІ-дій.

Роль: Freelance full-stack інженер / AI-інтеграція Термін: 3 місяці Домен: Sales CRM / управління лідами SaaS

Долучився до переписування в процесі й став основним контриб’ютором за час контракту — 1 366 з 2 888 комітів репозиторію, охоплюючи фронтенд, бекенд та шар AI-інтеграції.

Рішення

Платформа організована в незалежно версіоновані модулі, що ділять одну модель даних:

Talk — розмовний CRM-простір з дворівневою системою статусів та кількома режимами AI-асистенції
See — AI-згенеровані візуальні звіти та моделювання фінансових ризиків (“живі звіти”, що оновлюються разом із даними)
Decide — відстеження впливу рішень і токен-based білінг-леджер для ШІ-дій
Identity — організаційна структура: ролі, позиції, обчислена командна аналітика
Tenancy — автентифікація, ізоляція даних, контроль доступу на основі привілеїв
Steam Sync — прийом лідів із зовнішньої телефонії/CRM-системи, включно з транскрипцією дзвінків та призначенням агентів
Lead Intelligence — автоматизоване збагачення та скоринг лідів через зовнішній шар workflow-автоматизації

Ключові технічні рішення

AI gateway з provider fallback замість хардкоджених викликів

Кожен ШІ-код-шлях проходить через єдину gateway-функцію, а не викликає SDK провайдера напряму. Системні промпти живуть у таблиці БД (5-хвилинний TTL-кеш), тож зміна промпту не потребує деплою. Gateway викликає основного провайдера й автоматично перемикається на резервного при rate-limiting чи помилках на боці провайдера — ШІ-залежні функції (аналіз, переклад, підсумовування, скоринг) продовжують працювати під час збою провайдера замість того, щоб зламати весь пайплайн.

Детермінований, незмінний білінг-леджер

ШІ-дії споживають токен-based валюту, і кожна подія споживання записується в append-only леджер — жодна дія ніколи не змінює й не перезаписує попередній запис. Стан білінгу завжди відновлюваний повторним прогоном леджера — це важливо і для аудиту, і для дебагінгу “чому цей акаунт показує такий баланс” через кілька днів після факту.

Фонова обробка через cron замість роботи в request-time

23 продакшн cron-джоби обробляють синхронізацію, моніторинг та email поза циклом запит/відповідь — синхронізація лідів, авто-синхронізація result-code, планове оновлення довідкових даних, чергова доставка email. Винесення цієї роботи з request-шляху тримає розмовний робочий простір швидким незалежно від обсягу фонової синхронізації.

Trunk-based деплой у двох середовищах

Staging і production деплояться з однієї гілки (trunk-based з середини контракту) замість підтримки довгоживучої staging-гілки, яка розходиться з тим, що реально в продакшні. Це прибрало клас багів, які проявляються лише тому, що staging і production тихо виконували різний код.

Результати

Метрика	Значення
Розмір кодової бази	~123K рядків (фронтенд + edge functions)
Коміти (цей контракт)	1 366 з 2 888 загальних
Test-файли	201
Продакшн cron-джоби	23
Незалежно версіоновані модулі	7
AI-провайдери (gateway fallback)	2 (основний + резервний), плюс окремий стек збагачення/скорингу

Стек

Шар	Технологія
Фронтенд	React 19, TypeScript, Vite, Tailwind CSS
Стан / дані	TanStack React Query v5, React Router v7
Бекенд	Supabase (PostgreSQL, RLS, Edge Functions)
AI / LLM	Google Gemini (основний), OpenRouter (резервний), окремі провайдери збагачення/скорингу
Автоматизація	n8n (workflow збагачення лідів)
Інфраструктура	VPS + Nginx + Let’s Encrypt, trunk-based деплой у staging + production