Five inboxes are not five channels - they're five places where the query gets lost
Each channel has its own notification logic. The form sends an email to one person. Messenger sends a notification in an app that the employee checks less often than email. The phone leaves only a number on the display if no one answers. Email waits in the inbox until someone opens it. None of these channels knows about the others. The same question can come three times, and the answer may never come. That is what query handling automation is for: it collects these five inputs in one place. Each ticket gets an owner and a response deadline there.
- Each channel has its owner
- Ticket status known only by the one, who saw it
- Response time not counted anywhere
- One person's absence blocks the channel
- All channels go to the same place
- Each ticket has status and owner
- System calculates response time
- Lack of response raises escalation
Why this is not a theoretical problem
According to our data, the query in those companies is not saved anywhere.
None of them have their own place for queries. Before a company adds another contact channel, it's worth checking whether it has at least one place where the query gets saved.
What the queue looks like: trigger → routing → SLA → escalation
A ticket from a form, phone, Messenger or email first goes to the trigger. That's the rule that catches it and saves it in one system. Routing decides who gets it - a specific person, department or shift queue, depending on the time and topic. SLA is the deadline for the first response, counted from when the ticket came in, not from when someone notices it. Escalation kicks in when the deadline passes - the ticket goes to a supervisor or the second person in the queue. This chain works the same for the phone as for WhatsApp messages. All channels come in through the same entry point.
SLA thresholds set by company. Figure shows each row has state and rule.
Who and what actually participates
The trigger is usually backed by the CRM. That's where the query becomes a record, not just a message. CRM for your company connects the form, the WhatsApp Business API, Messenger and the email inbox into one ticket view. Reception or the service department sees the queue with deadlines instead of five separate apps. The owner gets a report on how many tickets waited longer than the agreed deadline. This is the job of AI reports, not another spreadsheet for manual counting. If the company handles conversations mainly through messengers, Messenger and WhatsApp integration becomes the entry point instead of the form.
- Form
- Phone
- Messenger
- CRM
- Owner notification
- Escalation
- Report
How much it costs
Scope and price — worked out after a conversation. The core is the query automation queue itself: trigger, routing, SLA. The rest depends on how many inputs have to be connected to it — each messenger, each mailbox and the form on the site is a separate piece of work, because each hands over its data differently. Assignment and escalation rules in the CRM are another stretch: without them the queue exists but nobody owns it. A company adds only the channels it actually has — which is why the scope cannot be stated in advance, before the conversation.
What breaks and who fixes it
Duplicates are the most common error. The same query comes from the form and from Messenger because the client wrote in two places. Without deduplication rules, the trigger creates two records, and two people call the same client. The WhatsApp Business API has limits on messages to new numbers. After exceeding the daily limit, the integration stops sending notifications, and the error is only visible in the provider's logs. Attachments most often get lost when they are forwarded from email to the CRM, if the integration copies only the link to the file, not the file itself. The link expires and the attachment disappears. These failures are the responsibility of whoever maintains the integration. It's worth settling in advance whether that is the client's IT department or the automation contractor.
When not to do this
A company with low query volume, where one person sees all tickets, doesn't need routing or escalation. The cost of such a queue will then exceed the benefit. The same applies to companies serving customers through only one channel - there the problem lies elsewhere, not in the number of inboxes. We don't promise a specific number of recovered queries or a specific reduction in response time - no one can honestly guarantee that. We guarantee the structure: one entry point, one ticket owner and a visible response deadline instead of a guess.
FAQ
Can query handling automation replace an employee?
No. The trigger and routing pass the ticket to the right person, and the response is still written by a human. Automation shortens the time between the query coming in and someone seeing it.
What if we only have a form and a phone, without messengers?
The queue works with two channels too. Email integration is often enough as a first step before further channels are added.
Do we need to replace the CRM to implement this?
Not always. The trigger and routing can be connected to an existing system if it has an API. Replacing the CRM is a separate decision, unrelated to the ticket queue itself.
How long does implementation take?
It depends on the number of channels and whether a CRM already exists. We don't give a deadline here without knowing the specific company - that's the first thing we settle in the conversation.
What happens to the query after the SLA is exceeded?
Escalation transfers it to a supervisor or the second person in the queue, according to the routing rule. The ticket doesn't disappear - it changes owner and is marked as overdue.
Let's talk about query handling automation for your company in Warsaw.