When a client sends an email about a contract, writes in a chat about an error, and calls a manager, the system might merge everything into one ticket. Then, the technical request gets lost in the contract discussion. To solve this problem, configure the registry so that counterparty identification is separated from the routing of their tasks.
Three channels, one client: the cost of fragmented reception
Illustrative scenario: a representative of a client company contacts a supplier through three different channels within one business day. First, they send an email to the general sales department address requesting an update to the annual contract. An hour later, they encounter a problem accessing the client portal and write to the technical support web chat. Later, they call their personal manager to discuss terms for connecting an additional service module.
In an unprepared operational environment, these three actions create three isolated entities that are processed in parallel without mutual context. The manager records the details of the phone conversation in their local spreadsheet or notebook. The chatbot generates a standard service ticket in the support system, assigning it to an available engineer. The email remains in the general sales department mailbox, waiting for manual processing. The lack of a unified electronic contract database and fragmented storage of related documents leads to information being difficult to find quickly or being lost entirely during the handoff between departments.
The consequence of such fragmentation is a disrupted customer experience and direct operational inefficiency. A manager who subsequently calls a client to sell an additional module is unaware that the customer is currently frustrated by a technical access error. When a sales department employee later manually forwards an email to a lawyer, the lawyer begins preparing an updated contract. They do not account for the need for the new module, as this information remained exclusively in the manager's notes. The company spends paid employee time on duplicating communication, clarifying status, and correcting errors that could have been avoided had a consolidated counterparty profile been available.
Sources: [2]
Identification versus intent: why simple merging does not work
An attempt to solve the problem of fragmentation through the implementation of rigid automatic deduplication rules often creates new operational risks. Merging all incoming messages from a single domain or phone number into a single request mistakenly interprets a match in contact details as a match in intent. A single client may have different needs simultaneously. Such an approach creates a dangerous trade-off between reducing the number of duplicates in the system and the risk of completely losing the context of requests that are different in nature. To test the effectiveness of the current algorithm, test the system with simultaneous requests regarding different issues from a single test domain; if the intents are different, the system should create linked but separate tasks with their own statuses.
When the system blindly merges requests, a routing conflict arises. A technical problem from a web chat is added as a standard text comment to a commercial request from an email. The sales department, which owns this merged ticket, ignores the technical comment because it does not concern contract terms and falls outside the competence of sales managers. At the same time, the support service does not see the request for access restoration at all, as it was intercepted by the commercial route. The incident resolution deadline is missed, and the client does not receive timely technical assistance.
Proper process architecture requires a clear separation of these two data processing levels. The first level answers the question of who exactly is contacting. Here, the system or operator must find a match by contact details and link the request to a single counterparty profile. The second level answers the question of what exactly the client needs at a specific moment. At this stage, it is determined whether the new message is a logical continuation of an already open dialogue or if it initiates a completely new business process with its own deadline and a different responsible department.
Decision criteria: link or merge
To avoid errors when qualifying multichannel requests, the first line of support or a dedicated dispatcher must be guided by standardized criteria. Every unclassified message from an identified client must undergo a mandatory check for affinity with open operational tasks.
If a client sends a clarification regarding a current contract or additional details, this message should be merged with the existing document approval task. However, if a client reports a new technical equipment malfunction, the dispatcher is obligated to create a new task. This new task is linked to the client profile but follows a different execution route. The decision to create or merge directly determines which department takes responsibility for the final result and which specific metrics will be used to evaluate performance. Increasing the urgency of a clarification to an already open task changes its priority or escalation, but does not in itself create a new task.
The table below demonstrates the decision-making logic when processing incoming signals from an existing client. It helps dispatchers standardize the choice between creating a new process and supplementing the current one, minimizing the risk of losing critical information during handoffs between departments.
| Dispatcher action | Acceptance criterion | Responsible for execution | System record |
|---|---|---|---|
| Merge with current task | The same intent within an open process; update its priority or escalation if necessary. | Current owner of the open task | New comment or attachment in the existing card |
| Create a new task | A different intent with its own expected outcome and separate execution route. | Specialized department (support, finance, legal) | New process card linked to the client profile |
| Reject as duplicate | Complete repetition of a previous message through a different communication channel | First-line dispatcher | Closed ticket with a cross-reference to the main task |
Architecture of the unified registry and routing
Implementing such an approach requires an IT architecture capable of supporting relational links between different database entities. The Scriptum platform is an example of a low-code solution for automating processes, forms, registries, and integrations. It allows for configuring a setup where the client profile exists as a separate independent record in the master registry, and all their various types of requests act as subordinate objects.
The operational manager must design the process so that unstructured requests pass through an initial qualification stage. At this stage, the operator uses a search form in the registry. Having found the client, the operator sees all their active tasks on one screen. If the new request does not match the content of any of them, the operator initiates a new form, for example, a technical support request or a contract change request.
Each such form has its own configured document route. A technical request is automatically directed to engineers with a defined SLA owner (e.g., an illustrative four hours, depending on the company's approved standards). A commercial request enters the sales department pipeline with a longer processing cycle. At the same time, the head of the customer service department, upon opening the counterparty card in the registry, sees the full picture: lawyers, engineers, and sales managers are working with the client simultaneously. This ensures operational transparency, significantly reducing the risk of losing specific requests in the general flow of unstructured communication.
Sources: [1]
Validation and execution control
Adding a dispatching stage requires strict control so that initial qualification does not become a bottleneck in the entire service process. The operational manager must track the time from receiving an incoming signal to the moment it is converted into a specific task with an assigned owner. The system must record the exact time an email or chat message arrives, the time the client profile is identified by the dispatcher, and the time the task is actually accepted for work by the specialized expert.
If a request remains unassigned longer than the established standard, the configured route must provide for automatic escalation to the shift supervisor. Confirmation from the initiator or the responsible manager signifies acceptance of the result for that specific task. The independence of parallel processes is ensured by separate records, status change rules, and access rights: closing a technical task should not automatically close a commercial one. Verify this with test records: after proper confirmation, close the technical task using the engineer's account, and then check that the status of the commercial task has not changed.
Action checklist
- Conduct an audit of deduplication rules: ensure that merging by email does not destroy the context of different requests.
- Separate client profile entities and operational tasks at the database architecture level.
- Appoint a responsible dispatcher for manual validation of requests that the system cannot uniquely classify.
- Configure separate approval routes for technical and commercial tasks linked to the same counterparty.
Questions and answers
What should I do if a client sent three identical requests through different channels?
The dispatcher identifies the client, leaves one task as the main one, and closes the others marked as duplicates with a cross-reference to the main request.
How to avoid duplicate profiles if a client uses a personal email?
Configure a manual verification process. The manager confirms the ownership of the address and adds it to the registry as an additional contact before processing the request.
Can the system automatically recognize a client's intent without a dispatcher?
Yes, provided a category is selected in the web form. For unstructured emails, manual qualification is necessary to avoid misrouting.