By Artem Korsakov ·
When a client writes to a messenger, the dispatcher calls the technician, and the result is stored in personal correspondence, it is difficult for management to reconstruct the workflow. A list of requests is useful only if it shows who currently handles the inquiry and what action should occur next.
Which request statuses to use
Let’s take a hypothetical company servicing retail equipment. The dispatcher receives the fault description, clarifies the model and contact details, then assigns an employee. The executor accepts the task, contacts the client, and records the result.
For a start, statuses such as "New," "Assigned," "In Progress," "Awaiting Data," and "Completed" are sufficient. Each status must have a definition. For example, "Assigned" means that an executor has been chosen, but they have not yet confirmed the start of work. Without a common meaning, employees will use identical names differently.
Separately define who is authorized to close an inquiry and under what circumstances it is returned for revision.
Подпись: Illustrative example. Each status has a definition and an executor responsible for the transition. If the technician does not confirm the assignment within the timeframe, the dispatcher selects another executor.
What is included in service request tracking
A minimal card should facilitate the work:
- Request number and submission date;
- Client, contact, and object address;
- Equipment and problem description;
- Responsible person and current status;
- Agreed next action;
- Comments and necessary attachments.
If data is insufficient, this should be visible. The field "model not installed" is more useful than a fabricated value. From a photo or short description, you cannot promise accurate diagnostics until a specialist has inspected it.
Do not turn the first card into a questionnaire with dozens of mandatory fields. First, collect information without which an inquiry cannot be accepted and transferred to an executor.
How to separate access rights
The dispatcher needs a general list and the ability to assign executors. The technician usually only needs their own tasks and necessary contacts. Management benefits from overdue inquiries and change history.
Restrictions must be tested on different accounts, including attempts to open another user's request via a direct link. A detailed breakdown of roles is available in the article on access rights in the personal portal.
Client access can be added as a subsequent stage. It shows statuses understandable to the client. Internal comments and team agreements are not visible to the client.
What is included in the first working version
A realistic starting volume: one method of intake, a general list of inquiries, a card, two or three roles, and status history. Notifications are connected through a single agreed channel after verifying its capabilities.
In such a version, the dispatcher can assign masters manually. Automatic distribution by route, workload, qualification, and parts availability already requires additional data and rules. These functions cannot be considered included simply because an assignment button is shown in the interface.
AI can help extract the model and description from text, but an employee must confirm the data. The decision on repair remains with the specialist.
What happens if a technician does not accept the request
Assignment and acceptance of a task are useful to separate. The dispatcher has selected a technician, but they may be out on another job, unreachable, or lacking the necessary qualification. For each assignment, record the time, confirmation deadline, and action in case of no response. The timeframe is set by your service rules; the developer does not choose it.
If a technician declines, the card retains the reason and the new responsible person. In case of urgent reassignment, the first executor must see that the task is no longer theirs. Two parallel trips to one address should not become the standard way to correct delays.
Work can be organized in existing tools: Bitrix24 (a CRM and collaboration platform) supports stages, fields, rights, and smart-process robots. A separate product is needed where a verified configuration does not cover the service route.
AI in the card: an example instead of a diagnostic promise
The client writes: "The display case is not cooling, it makes noise after turning on. The address is the same as last time." The assistant extracts symptoms and notes omissions: the model is not named, the address requires confirmation. The dispatcher opens quotes from the inquiry, clarifies the data, and saves the card. Automatically substituting the address of the last visit is impossible: the company may have multiple locations.
After the work, the technician writes the result. The AI suggests a short summary for the dispatcher and a list of mentioned subsequent actions. If the technician reports "a part is needed," a separate task appears, and the status "repair completed" is not set. The technical cause and operability are confirmed by a specialist.
The first pilot should be limited to one type of equipment and a group of executors. In the log, review average assignment time, longest requests, re-openings, and closures without result descriptions. These metrics show whether managing the department has become easier.
Подпись: Illustrative example. The AI extracts symptoms and notes omissions. The address of the previous visit is not automatically substituted: the client may have multiple locations.
What to check before launch
Walk through a standard request from creation to closure. Then test incomplete contact details, changing the executor, resending the form, returning for revision, and a situation without notification. A new request must be saved even when an additional message is not delivered.
Result indicators may include assignment time and the number of inquiries without a responsible person. These are compared on real tasks, without promising a predetermined percentage of improvement.
With trike_dev, you can analyze your request route and determine the composition of the first version. Demo client portal shows work with requests and documents; the exact dispatcher logic will be agreed separately.
Related reading: Personal portal for clients: how to show order status; Automation efficiency: how to verify implementation results.
Частые вопросы ### Can we work from a phone?
Yes, if mobile actions are included in the project scope and tested on employees' devices. Changing status, adding a comment, and opening attachments are especially important.
Will the system account for inventory?
Only if inventory accounting and its connection are separately agreed. For tracking inquiries, full synchronization with the warehouse is not mandatory.