Agent guide
This page is for support agents and Service Desk managers — the people who work incoming customer requests. Customers use the separate customer portal.
A customer request is a normal issue inside TaskFlow, so everything in Issues & tasks applies — plus the Service-Desk tools below.
Working from queues
A queue is a saved filter over requests — Unassigned, High priority, Incidents. A queue lives inside a project and is built from filters on status, priority, labels, assignee — a specific person or "unassigned" — and request types, so each one keeps itself current; the list shows newest first.
A queue shows the request key, subject, status, priority, assignee, due date and when it was last updated.
Typical flow:
- Open a queue and pick up the next request.
- Assign it to yourself and move it into progress.
- Reply to the customer by commenting — see the note on internal comments below.
- Resolve the request when the work is done.
Replying vs taking notes
The issue's comment box has an Internal switch, and getting it right matters:
- A normal comment is a reply to the customer. They see it in the portal, and they're emailed that you've answered.
- An internal comment is for your team only. The customer never sees it.
Use internal comments for diagnosis, hand-offs and anything you wouldn't say to the customer directly. An internal comment carries an Internal badge, and the switch is still there when editing. Check it before sending all the same: the customer's email for a normal comment goes out immediately, and clearing the flag later won't recall it.
Replies happen in the portal
Customers are emailed a link when you answer, and they respond in the portal. Incoming email doesn't become a comment, so a customer who replies to the notification isn't reaching you — the email tells them so.
SLAs
Requests can carry SLA timers — targets such as "first response within 2 hours" or "resolve within 8 working hours". On a request you can see which goals apply, how much time remains against each, and whether it's running, paused, met or breached.
Timers start, stop and pause on status changes, and they honour the configured working hours and time zone, so an out-of-hours request doesn't burn its target overnight.
A breach doesn't notify anyone by itself
SLA tracks and displays; it doesn't escalate. If you want a warning before a breach or an action on one, build an automation rule — the SLA conditions breached, minutes until breach and timer running are available to rules.
Approvals
Some requests need approval before work proceeds. On such a request you can start an approval chain and see each step's decision, with approvers recording approve or decline and an optional comment. Chains are defined by managers, each step naming how many approvals it needs.
Knowledge base
Agents and managers maintain the knowledge base. Each article has a title, tags, content, a visibility, and a Published flag:
- Public — customers can read it in the portal, and it can be suggested to them as they fill in a request form.
- Internal — for your team only; it is never shown to customers.
A customer only sees an article that is both public and published — a new article starts out unpublished. Articles can be linked to request types, which is what drives those suggestions on the portal form. A well-linked article deflects the request entirely.
CSAT
After resolution, customers can rate the service and leave a comment. The CSAT page shows the average score, how many ratings you've had, and the distribution across scores — for all projects or a selected one — so you can see the shape of the feedback rather than just the average. CSAT scores are also available as an automation condition — a low rating can raise a follow-up automatically.
Configuration
Managers and administrators configure the Service Desk under Admin → Service Desk:
| Page | What you set up |
|---|---|
| Service Desk | Customer access switches, the mail transport for customer replies, and a link to open the portal. |
| Request types | The kinds of help customers can ask for, each mapped to a project and issue type, with the fields its form asks for. |
| Queues | The saved filters agents work from. |
| Customers | Customer profiles — company, phone, and the external customer ID (their number in your billing or CRM). |
| Approvals | Approval chains and their steps. |
| Knowledge base | Articles, their visibility and which request types they relate to. |
| CSAT | Satisfaction results. |
Customer access
Two switches control the portal, independently of the internal instance's own sign-in settings:
- Block customer registration — customers can't create their own accounts; you create them.
- Block customer sign-in — the portal sign-in form is closed. People already signed in aren't kicked out: an open tab keeps working for as long as it keeps renewing its session. To cut access immediately, disable the accounts themselves.
Both apply within seconds, with no restart.
Email to customers
Replies reach customers by email only once a transport is assigned for Service Desk mail — selected on the Service Desk page. Until then, customers see replies in the portal but aren't told about them. See Email.
Whether the messages about one request arrive as a single thread in the customer's mailbox depends on the transport: those that support threading keep the conversation together, while the platform gateway sends each message separately.
Where to go next
- Customer portal — what your customers see.
- Automation — escalations and follow-ups.
- Project configuration → SLAs — policies, goals and working hours.