Most of a support team's day isn't spent on the hard answers. It goes on the sorting: reading each message to work out what it is, how urgent it is, who should have it, whether it's really a bug, and typing an answer that's already written down somewhere. That reading is exactly what AI is good at. The reply a customer receives is where a person should stay.
Triage comes down to four moves: sort each message, route it to whoever handles it, draft the answer, and escalate what can't wait. Here are six ready-made workflows from Lodol's library that make those moves, and how to build the same pattern around the help desk you already use.
1. Draft every reply, send only what you approve
The workflow: every hour, Review and send replies to support enquiries reads the unread support mail your Gmail search finds and has AI write a reply to each message, working from a short description of your business, your tone and anything a reply must never promise, which you write once. Before anything reaches the customer, you're asked to approve the reply, shown in full next to what the customer wrote. Approve it and it goes as a reply in the customer's own conversation.
What it won't do: answer what it doesn't know, or send what nobody approved. A question your description doesn't cover gets a short acknowledgment saying a colleague will follow up, never an invented answer. Reject a reply, or leave it, and it's saved as a Gmail draft in that conversation instead, so nothing is lost. If you don't name approvers, anyone in your Lodol workspace can approve, so name them for a shared inbox.
2. Turn requests into tickets for the team that fixes them
The workflow: whenever someone posts in the Slack channel you choose, Turn Slack support requests into Linear tickets has AI decide whether the message is a real request for help, rather than a greeting, a thank-you or a reply about something already raised. A real request becomes a Linear ticket with a short title and a body saying what's being asked for, what's affected and what's still unknown. Someone who is blocked right now gets high priority instead of medium, and a reply in the Slack thread gives them the ticket reference and link.
What it won't do: flood the tracker. A close call is left alone, because a ticket for every message is no better than no tracker. Gaps are listed as gaps, not guessed at, and the reporter's own message is added to the ticket word for word as its first comment, so the summary can always be checked against what was said.
3. Answer the questions your docs already cover
The workflow: when someone asks a question in your Slack channel, Answer Slack questions from your Notion FAQ finds the Notion pages whose titles match, reads each page's properties, and drafts a short answer built only from what those pages say, naming the page each point came from. The draft comes to you for approval before it reaches the channel.
What it won't do: fill a gap in your FAQ. If no page matches, or the pages found don't cover the question, the thread is told so. Reject the draft, or leave it for three days, and only the page links are shared. One limit to know: it reads page titles and properties, not page bodies, so it works best on an FAQ kept as a Notion database with the answer in a property.
4. Sort a busy community into the right channels
The workflow: Send community posts to the right channel reads each new post in your main Discord channel and decides whether it's a support question, a bug report, a feature idea, ordinary chatter or unclear. Support questions, bugs and ideas are forwarded to the channel that handles each, with who posted, what they said and a link back to the original, so whoever picks it up can act at once.
What it won't do: force a fit. Chatter, and anything too short or ambiguous to call, is left where it is rather than filed as something it might not be. Each post goes to one channel at most.
5. Hand a chat to a person the moment it needs one
The workflow: Telegram support bot that hands over to a person replies to every customer who writes to your Telegram bot, answering from the support material you give it. It's the one workflow here that answers customers without a person reading first, so it's built to hand over early.
What it won't do: handle what a person should. Handing over is the rule, not the exception: refunds, billing, cancellations, complaints, anything about safety or personal data, and anything your material doesn't cover all go to a person. The colleague who takes handovers is sent the message first, and only once that's gone through is the customer told someone will get back to them. A draft that claims an account was fixed, refunded or closed is handed over instead of sent.
6. Spot the accounts that are slipping
The workflow: every Monday at 8:00, Score client health from your email log reads the client emails you've logged in a spreadsheet, and AI summarizes each new one and scores how satisfied the client sounds, from 1 (about to leave) to 10 (delighted). A client health tab keeps one row per client with their latest score, a status of Healthy, Watch or At risk, and the trend since their last email. The ones marked At risk are this week's calls.
What it won't do: score twice or overwrite on a bad answer. Each email is scored once, and a reply with no readable score leaves the client's row untouched until next week.
Build the same pattern around your help desk
If your tickets live in a help desk rather than an inbox, the same four moves work there. Lodol can raise, update and search tickets in Zendesk and ServiceNow, work service desks, queues and requests in Jira Service Management, raise and reply to tickets in Freshservice, and, from today, reply, comment, tag, assign and snooze conversations in Front's shared inboxes. A triage workflow usually looks like this:
- Read and sort. An AI step from Anthropic or OpenAI reads the message and answers with exactly one category from your own list, such as urgent, question, bug or billing. Give it an "unclear" option, so a borderline message has somewhere honest to go.
- Route. An If / Else, with an Else if for each category, sends each one its own way: an urgent message to a Slack direct message, a bug to Linear or Jira with the customer's own words, a question to the drafting steps, and unclear to a person.
- Draft, then ask. A Request approval step pauses the run and shows the draft to whoever you name, in Lodol, by email or posted to a Slack channel. You choose how long they have and what happens if nobody answers, and the steps after it act on their decision.
- Plan for failure. Wrap the steps that talk to other apps in a Try / Catch, so if the help desk doesn't answer, the run posts a note to Slack instead of losing the ticket.
Every run is recorded step by step, so when a customer says they never heard back, you can see what was drafted, who approved it and when it went. For a personal inbox rather than a shared one, Draft a reply to every new email in your voice saves a draft under each email and leaves a square-bracketed blank wherever it needs a fact it doesn't have, rather than inventing a price, a date or a promise.
Start with the support inbox.
Add Review and send replies to support enquiries, point it at your support mail and approve the first drafts yourself. Or browse all of the customer support workflows, and see how Lodol fits a support team on the customer support page. Start free if you don't have a workspace yet.