About Processing Requests in ConnectiveOne
Request — communication of a client with a company to get help, resolve a problem, or provide feedback. ConnectiveOne supports different types of requests (chat, ticket, task), each with its own features and used for different scenarios. This page explains the principles of request processing, request types, and stages of their lifecycle.
Context and Problem
Clients contact the company through various channels with different questions and problems. Each request has its own features:
- Different types of problems require different approaches to processing
- Different communication channels have different capabilities and limitations
- Different resolution terms — from instant responses to long-term tasks
- Coordination needed between operators and departments
ConnectiveOne solves this task by providing a flexible request processing system that adapts to different types of queries and business processes.
Key Concepts
Request Types
Chat
Chat is a request resolved in real time, usually by one employee. Suitable for quick queries and resolving standard problems.
Characteristics:
- Includes two or more participants
- Problem is resolved in real time
- Priorities — standard, statuses are optional
- Suitable for quick queries and resolving standard problems
Example: A client in a supermarket cannot find a specific product and initiates a chat through a mobile app to clarify product availability.
Ticket
Ticket is a request processed over a period of time and can be transferred between employees for further processing.
Characteristics:
- May contain one or more participants
- Problem is accepted and documented for thorough resolution
- Can be transferred between employees
- Priorities are customized, statuses move only "forward" to completion
Example: A checkout counter in a supermarket is not working. The cashier registers a ticket about the problem, and it is transferred to the technical team. First, the problem is diagnosed, then resolved. The ticket is closed after resolution.
Another Example: A client complains that they were treated rudely at checkout and calls the supermarket hotline. The operator creates a ticket that is transferred to the store manager for review. The manager conducts an investigation, takes necessary measures, and informs the client about results.
Task
Task is a long-term request that describes what needs to be done and is often transferred between employees for execution.
Characteristics:
- May include one or more participants
- Usually has long-term nature
- Describes what needs to be done
- Often transferred between employees for execution
- Priorities are complex, as is the processing process (status flow)
Example: Supermarket management decides to launch a new promotion. For this, a task is created that includes planning, approval, preparation of materials, and launch of the promotion. This task can be transferred between marketing, finance, and operations management departments.
👉 Note: Currently, we do not process tasks, but plan to implement them in the future for more comprehensive management of long-term assignments.
Request Processing Stages
Channel
Client starts a request through the chosen communication channel. ConnectiveOne supports various channels:
- Email — traditional channel for official requests
- Messengers — convenient way to communicate through popular apps (Telegram, Viber, WhatsApp, Facebook Messenger, Instagram)
- API — integration with other systems for automated information exchange
- Comments, stories — requests through social networks and platforms
- Mobile app (via Custom Channel or MobileSDK) — special functions for clients in company app
- Custom channels — any third-party systems integrated for receiving requests
- Calls (in product roadmap) — processing requests through voice calls
- Forms (in the future) — online forms for collecting queries
Query
Client creates a query by filling in necessary fields, which may vary depending on request type and problem.
Request Fields:
- Description — required field that is always present. In chat, everything starts with the client describing their problem
- Title — for email this is a required field. For other channels, it may be absent or generated by operator or AI from description
- Topic — selected by the client themselves or determined by AI based on request content
- Query Fields — depending on request topic, fields change (if it's a ticket). For example, "broken printer" and "expired product on shelf" require different sets of fields when creating, processing, and closing the ticket
- Priority — determines urgency of request resolution
- Initial Status — starting state of request in the system
Queue
Query enters the queue, where it waits for processing.
Distribution in Queue and Assignment:
- Skill Group — determined by request topic and helps assign it to the appropriate specialist
- Position in Queue — can be automatic distribution or operator takes request manually
- Assignee — specific agent who will process the request
Processing
Employee begins resolving the query.
Processing Process:
- Field Changes — updating information in the request
- Chat Correspondence and Notes — communication with client and internal comments
- Change Assignee and Escalation — transferring request to another employee or to a higher level, configured using escalation scenarios
- Sub-tasks — creating sub-tasks for resolving complex problems (in external task trackers)
- SLA — tracking standard metrics such as FRT (First Response Time), Time to Resolution, etc.
- Notifications — messages to assignee agent and watchers about changes in the request
- Status — processing ends when agent sets "closing" status
Result
After processing completion, client receives confirmation about problem resolution.
Result Elements:
- CSAT — client satisfaction rating
- Resolution Confirmation — client is informed about request closure
- Metrics — all statistics for this request are recorded for further analysis
Approach Options
Chat vs Ticket vs Task
Chat:
- ✅ Pros: Quick resolution, simplicity, instant communication
- ❌ Cons: Not suitable for complex problems that require long processing
Ticket:
- ✅ Pros: Structured processing, ability to transfer between operators, SLA tracking
- ❌ Cons: More formal process, may be slower
Task:
- ✅ Pros: Suitable for long-term projects, complex processes
- ❌ Cons: Currently not implemented in the system
Why We Use Different Types: Different request types suit different scenarios. Chat — for quick queries, ticket — for complex problems that require structured processing, task — for long-term projects (in the future).
Adopted Solutions
Channel Flexibility
ConnectiveOne supports all major communication channels, allowing clients to contact through their convenient method. This ensures maximum availability and convenience.
Adaptive Fields
Request fields change depending on topic and request type. This allows collecting relevant information for each specific case.
Automatic Distribution
The system automatically distributes requests between operators considering their skills (skill groups), load, and other criteria. This ensures fair load distribution and efficient use of resources.
SLA Tracking
The system tracks key SLA metrics (First Response Time, Time to Resolution, etc.), allowing controlling service quality and timely responding to problems.
Implications for Users and Implementation
For Operators
When processing requests, it's important to:
- Determine request type — is it a quick query (chat) or a more complex problem (ticket)
- Fill all necessary fields — for correct processing and reporting
- Track SLA — for ensuring service quality
- Use escalation — when help from other specialists is needed
For Supervisors
When managing request processing, it's important to:
- Configure skill groups — for correct request distribution
- Track metrics — for controlling quality and efficiency
- Analyze CSAT — for improving service
- Configure SLA — for controlling resolution terms
Common Errors
Error: Using chat for complex problems
Problem: Chat is not suitable for problems that require long processing
Solution: Create tickets for complex problems that require structured processing
Error: Incorrect field filling
Problem: Lack of necessary information complicates processing
Solution: Always fill all required fields and relevant custom fields
Error: SLA Violation
Problem: Requests are not processed on time
Solution: Track SLA metrics and escalate problems in time
Related Documents
- Explanation: About Auto-Distribution of Dialogs Between Operators — how the system automatically distributes requests
- How-to: Create Ticket — instruction for creating a ticket
- How-to: Open Request — instruction for opening a request
- How-to: Reply to Client — instruction for replying to client
- How-to: View Ticket SLA Metrics — instruction for viewing SLA metrics
- Reference: Terminology Reference — definitions of terms CSAT, SLA Metrics, Skill Group