OmniCRM: From Conversation to Commercial Operation in One Platform

The problem starts before the CRM

A conversation arrives through WhatsApp. Another continues over email. An old contact reappears on Telegram. Meanwhile, important customer information becomes scattered across messages, notes, proposals, and tasks.

The challenge is not merely replying through multiple channels. It is preventing commercial context from disappearing when a conversation changes channel, owner, or stage. Without a unified view, a team may still answer customers, but it struggles to understand who the contact is, what has already been agreed, and what should happen next.

OmniCRM was created to connect these parts. The platform brings conversations, contacts, leads, customers, catalog items, proposals, projects, tasks, and campaigns into a single flow. A message stops being an isolated record and starts contributing to a commercial relationship that can be followed over time.

The inbox is the beginning, not the destination

The system's core is an inbox designed for WhatsApp, Telegram, email, SMS, and web conversations. Each conversation preserves its source channel, contact, owner, status, messages, and follow-up signals.

The interface supports open, pending, and completed conversations, unread state, assignment, tags, and follow-up notes. History remains attached to the contact, so every new message does not force the team to reconstruct the relationship from scratch.

Real-time communication uses WebSocket. New messages, state changes, and conversation events can therefore reach the interface without requiring a manual page refresh. In a multi-agent operation, this reduces conflicting actions and makes a shared queue more predictable.

Centralizing channels, however, solves only the first part of the problem. The real value appears when the system turns conversation content into useful sales and relationship context.

When a conversation becomes a lead

OmniCRM uses a LangGraph workflow to analyze conversations and identify potential leads. The flow loads message history, extracts name, email, phone number, and company, records confidence for each field, and checks for duplicates before creating a record.

The decision does not depend merely on the model producing some text. Minimum confidence thresholds apply: the name must be sufficiently clear, and at least one identifier—email or phone—must be reliable. If evidence is weak or the contact already exists, the workflow can finish without creating another lead.

This distinction matters because probabilistic extraction and persistence are different responsibilities. AI interprets the conversation; deterministic rules decide whether the available data is sufficient and whether a write may occur.

After capture, the profile can be enriched with signals already present in the relationship: the contact's likely role, stated pain points, associated company, and qualification information. Observed facts and inferences remain separate, including confidence and rationale when available. The operator can understand where a conclusion came from instead of receiving an apparently complete profile with no traceable source.

Qualification that can be explained

Leads do not receive only an opaque label. The scoring mechanism evaluates identity completeness, company context, problem signals, engagement, and duplicate risk.

The result contains a score, qualification label, calculation confidence, rule version, and a breakdown of the factors behind the number. When important information is absent, the system can mark the result as low confidence rather than communicating precision that does not exist.

This makes qualification adjustable and auditable. Teams can see why a lead is considered hot, warm, or cold and which information is still missing. The score helps prioritize work without hiding the decision inside an impossible-to-inspect formula.

AI that assists the operator

Artificial intelligence also supports daily service. Based on recent messages, the system can generate three concise reply suggestions in the language used by the customer. The operator remains in control, deciding whether a suggestion fits the context and how the conversation should continue.

For outreach, OmniCRM assembles grounded context from lead, conversation, customer, project, proposal, and catalog data. Sensitive information is omitted, and each context item retains a reference to its source. If there is not enough evidence for personalization, the instruction is to use neutral language without unsupported claims.

The goal is not to let a model improvise about a customer. It is to provide useful context within explicit boundaries: use available facts, distinguish inferences, and avoid inventing sales arguments.

From opportunity to execution

The commercial flow does not end when a lead is identified. The catalog stores products and services; proposals organize items, pricing, expiration, and states such as draft, sent, approved, or rejected; and projects track the continuation of the work.

A project may be created manually or originate from a conversation, receive a priority, move through commercial stages, and contain tasks. Tasks have their own states and may represent conventional work or scheduled activities such as sending a message.

Outreach campaigns complete the cycle. A team can select leads directly or create segments based on status, channel, qualification, and minimum score. The service prevents a lead from simultaneously joining conflicting active sequences, supports pause and resume operations, and records relevant state transitions.

With these elements connected, the platform preserves continuity between what the customer said and what the company needs to do next: reply, qualify, prepare a proposal, deliver a project, or maintain the relationship.

Operational control is part of the product

A platform that concentrates messages and commercial data must treat security and governance as part of daily work.

OmniCRM includes configurable role-based access control. Permissions cover conversations, messages, users, settings, branding, AI models, and audit logs. Viewing every conversation, deleting content, or changing an integration therefore requires more than simply finding the right screen.

Authentication integrates with Supabase, and tokens are held in HttpOnly cookies. Sensitive provider and channel credentials use an encrypted storage type, while request limits help protect exposed endpoints. Relevant actions produce audit records containing the user, resource, and operational context.

These mechanisms do not make a system automatically immune to failure, but they establish explicit boundaries. The same product that makes customer communication easier must constrain who can access data, change configuration, or perform a sensitive action.

The architecture behind the experience

The frontend uses Next.js, React, TypeScript, and Tailwind CSS. The backend is a FastAPI service with Pydantic schemas, domain services, and repositories that isolate data access.

PostgreSQL acts as the source of truth for users, contacts, conversations, messages, leads, customers, proposals, projects, campaigns, and audit data. SQLAlchemy represents the model, while Alembic maintains migration history. WebSocket connects the transactional layer to the real-time experience.

Channel integrations are contained in dedicated services for Telegram, WhatsApp, email, and SMS. This keeps operational rules—such as conversation ownership, delivery state, and message creation—inside the product core while isolating provider-specific details in their adapters.

Deployment also separates responsibilities: the backend is prepared for Docker and Coolify, while the frontend can be published to Vercel. Database migrations run during container startup before the application, preventing an ordinary request from becoming responsible for changing the schema.

The problems this architecture solves

Fragmented context. Conversations and commercial data share the same entities and references.

Duplicate or incomplete leads. Identification, minimum confidence, and identity resolution precede creation and prioritization.

Customer service disconnected from sales. A conversation can feed leads, proposals, projects, tasks, and campaigns without manual copying between tools.

AI without evidence. Suggestions, enrichment, and personalization operate with bounded context, a distinction between facts and inferences, and neutral behavior when data is missing.

Generic permissions. Configurable roles and audit records make it explicit who can view, administer, and change each part of the platform.

Operations without continuity. States, owners, follow-ups, and real-time events preserve the next action even when service changes person or channel.

The main lesson

Building an omnichannel CRM is not about placing several channel icons on the same screen. It is about creating continuity between communication, identity, and execution.

In OmniCRM, every conversation can become structured context, every lead can carry the evidence behind its qualification, and every opportunity can continue into proposals, projects, and new outreach actions. AI participates in that flow to reduce manual work and reveal signals, while rules, permissions, and history remain under software control.

The result is more than a shared inbox: it is an operational foundation where customer service and the commercial process no longer work as separate worlds.