In a hypothetical example, equipment is sold and the deal is successfully closed. A week later, the customer reports a problem. The salesperson reopens the sale and moves it backwards through stages. Service is underway, while the sales report looks surprised.
Describe after-sales support as a separate piece of work. Keep the customer link, while avoiding unnecessary changes to the outcome of an already completed sale.
Define the unit of work first
One short question may need a task. A request with diagnosis, approval, fulfilment, its own deadlines and materials may justify a separate process.
Write down what you track: a request, a specific item, a visit, or a repair. One customer can raise several issues. Putting everything in a single “Comment” field soon creates a novel without a contents page.
Do not label every service request a new sale. Chargeable work and commitments under an existing order may need different accounting rules.
Choosing a Bitrix24 tool
A simple assignment can use a task linked to the necessary information. For a separate request register, consider a smart process: a configurable record type with its own form, stages and relationships.
The official documentation describes these capabilities. Smart processes are not available on every plan. Check the section and required relationships on the particular portal before promising a solution.
If the company already uses a suitable service system, assess integration with CRM first. Matching screen designs alone is no reason to move a working service operation.
A hypothetical request journey
For training, stages might be received, clarification needed, diagnosis, solution approved, completed, and outcome checked. This is a proposed design, not a mandatory set of standard product stages.
Useful record details include the issue, links to the buyer and order, an owner, the promised next contact, and the check result. Technical materials should be accessible to the assignee under company rules.
For customers in Kazakhstan, agree on communication language and actual service hours. Do not promise round-the-clock replies if the team works ordinary hours.
Track waiting, not only overdue work
A request may wait for a customer or a spare part. Leaving everything “in progress” hides the reason for delay.
Every waiting state needs a reason, someone responsible for the next contact, and a review date. Add automatic reminders after checking automation and plan availability.
Test a return for clarification, reassignment, and a repeat request about the same issue. Separately verify that closing service does not alter the original sale’s amount or status.
When the work is actually complete
“The technician finished” and “The customer’s issue is resolved” describe different outcomes. Agree who accepts the result, what confirmation is stored, and what happens if the issue returns.
QQDev configures cross-team processes and develops existing Bitrix24 systems. Use the business processes page to discuss the journey of one service request. Begin with a hypothetical example: what happened after purchase, who gets involved, and how you check the outcome.