WSupport
How to set up customer support and SLA tracking
If support requests are scattered between email and WhatsApp, your response times aren't being measured — and what isn't measured can't be managed. This page shows how a multi-channel support operation is consolidated into one queue and how SLA discipline is built in the WApps business management ecosystem.
Start your 30-day free trialWeb based·One WApps account·4 key outcomes·Page updated: 25 July 2026
Product video1:51
Interface previewWSupport / WApps
●wapps.wcanx.co/app/support
Interactive mini demo
Try it now:Tap New request and submit it from the customer’s point of view.
My requests
Track the requests you opened and their current status here.
This portal belongs to this customer only; records of other customers are never visible.
What are customer support and SLA?
Customer support is the practice of recording an incoming request and tracking it through to resolution; an SLA (service level agreement) is the written commitment for how quickly those requests will be answered and resolved. When requests are scattered across email and chat, response time cannot be measured — and what cannot be measured cannot be committed to or managed.
01
Problem and approach
One inbox per channel, requests without owners
When one person watches email and another watches WhatsApp, requests live in personal inboxes. Nobody knows who replied to what; requests wait while their owner is on leave; a customer asking the same question on two channels gets two different answers. Because promised response times are measured nowhere, the SLA exists only in the contract — it has no counterpart in the operation.
Target flow: every channel in one queueTarget flow: every ticket has an ownerTarget flow: the SLA lives in the operation
02
Impact on the workflow
Impact on the workflow
Target flow: every channel in one queue
Email and WhatsApp requests land in the same queue as tickets and are managed from a single list regardless of channel.
Target flow: every ticket has an owner
Requests are assigned to team members; handing over during leave or load is a single action. No request goes unowned.
Target flow: the SLA lives in the operation
Response and resolution targets are defined in the system; approaching and overdue requests are highlighted in the panel. The SLA moves from contract to operation.
Target flow: history next to the customer
03
Implementation notes
Implementation notes
WSupport is built for this flow
Multi-channel ticket intake, assignment, SLA tracking and customer history are built into WSupport; tickets open from WLeads in one click.
What should you measure?
Four numbers are enough for a support operation: time from a request opening to the first reply, total time to resolution, the share of requests that pass their due date, and the distribution across priorities. WSupport derives all four from the request record, so no separate sheet is required.
Work it out with your own numbers
Try it with your figures: if you receive N requests a month and each generates K extra conversations purely about its status, status questions alone cost N×K touches a month. To see how much a customer portal removes, record your current K first.
What setup this runs on
This flow is built with WSupport and WTask together: the customer opens a request from the portal, the work progresses in your team's WTask queue, and the status reflects back to the portal. Monthly allocated hours are defined on the customer record and shown in the portal.
04
Continue exploring
Continue exploring
Next step