Set up Support for your team.

#Turn Support on

Support is an add-on that Revvly switches on for your workspace; it is not a setting you flip yourself. When it is on, a Support section appears in the sidebar (Inbox, End users, Knowledge, Guidelines, Metrics) and a Support tab appears under Org Settings. If you cannot see them, ask Revvly to turn it on. The first time it is switched on, Revvly sets up sensible defaults: a ticket prefix made from your workspace name (AcceleratorApp becomes AA), three ticket types with their workflows. You can change all of them. There are no ready-made roles: you define your own; see below.

Every active member of the workspace can work tickets. Only admins and owners can change these settings; other members see the pages read-only with a notice. Add people with Add a team member.

#General settings

#Roles

A role is a kind of customer who should see different help articles, such as Founder or Mentor. Revvly has no built-in roles: you define every one. You do not change what your system sends to fit Revvly. Instead each role says which values it matches in what your system already sends about a person: their role value, or one of their attributes. A person can have several roles, and reads articles open to any of them plus everything open to everyone. A person who matches none reads only what is open to everyone.

Changes to a role apply to the next answer: there is no need to sign anyone in again. Deleting a role takes it off every article. An article that only that role could read is never opened to everyone: it waits under Needs a decision, out of answers, until you choose who can read it. The delete confirmation tells you how many articles name the role.

People appear under Support, End users once they have signed in to the chat or been synced by your system, with the roles they match.

#Ticket types and workflows

A type is a kind of request that the customer picks. Each type uses a workflow: an ordered list of statuses. Three types are set up for you: Question (New, Answered, Closed), Issue report (New, Replicated, Escalated, In development, Resolved, Closed) and Suggestion (Received, Under review, Accepted, In roadmap, Delivered, Declined, Closed). Several types can share a workflow.

Existing tickets stay valid when you edit. A saved status keeps its category and is retired instead of removed. Every workflow keeps at least one open status and one closed status, and at least one type stays live. A type’s workflow is fixed once it has tickets; to use another, create a new type. Retiring a type stops new requests of that kind.

#Teams and assignment

Create a team there, then on a ticket choose it in the Team chip, and in the inbox filter by it. A ticket’s team and assignee are independent: a team can hold tickets nobody has taken yet. Assignment rules (sending tickets to a team or person automatically) are not built; tickets are taken and assigned by people.

#Notifications

For agents. Each agent sets their own, from the bell and its Notification preferences link (Support, Notifications). Each kind can reach them in the app, by email, or both:

The email carries the ticket number, title and a link, never the message text, and is sent promptly, and not at all if it is more than a day old by the time it could go. Nobody is notified of their own action.

For customers. Two choices belong to the customer, not to you, and your system cannot switch them back on for them:

• Email about an unread reply: on by default. You set how long to wait under General. Every email has a Turn off these emails link, and your chat can offer the same choice.
• Progress updates on the work behind a request: All (every stage that notifies), Final (only the last stage) or None. It controls the messages described under client updates.

Offering them to customers is part of your chat; see Support chat API, notification preferences.

#Client updates

When a ticket is backed by work in ClickUp, the customer never sees ClickUp’s statuses. They see stages that you name: Received, Confirmed, In development, In testing and Released to begin with. You can rename, reorder, add and remove them. For each stage:

• Tell the client when their request reaches this stage sends them a message. You write it, using only {{title}}, {{stage}} and {{number}}, up to 500 characters; a preview shows what they read.
• Also tell them if the work moves back into this stage: by default only forward moves are announced.
• When work reaches this stage, move the ticket to a status. A closed status cannot be chosen, so a close always carries a resolution an agent chose.

Each stage is announced at most once per request, only when the work moves forward, and after a ten minute wait so that several quick moves make one message about the latest stage. Two more options are at the bottom: tell a customer who has already closed their request, and add a comment to the linked ClickUp task when a ticket changes status, closes or reopens. Below, ClickUp statuses maps each status of a ClickUp list to a stage; statuses you leave unmapped stay internal.

#Link ClickUp tasks

On a ticket, the ClickUp panel can Create ClickUp task (choose the list, or let the default list for that type apply) or take a pasted ClickUp task link. Up to ten tasks can be linked to one ticket, and one ticket can only have one task created from it. A task Revvly creates carries the ticket number and link, its type and priority, the client, who asked (name, role and plan) and their first public message. It never carries an internal note or an email address.

Revvly only ever adds to ClickUp: it creates tasks, and writes a comment on the tasks it linked. It does not move or edit an existing task. Status changes in ClickUp usually reach the ticket within moments, and a check every 15 minutes repairs anything missed. The default list for each type is set under Org Settings, Support, Client updates, Where tasks start.

#Webhooks

Revvly posts the ticket events you choose to your backend, signed, so it can pass them on to your users or react to them. Enter an https address and tick the events you want. Each endpoint has its own signing secret, shown once when you create it; Rotate secret replaces it. Send test event checks that your backend answers. If an endpoint fails ten deliveries in a row it is turned off until you turn it on again, and each delivery is retried up to six times first. Delivery history is kept for 30 days and a finished delivery can be replayed. The body and signature are described in the Support chat API reference.

#Secret keys

Your backend uses a secret key to sign customers in to the chat. It stays on your server. Limits sets how many requests a key may make per second and per minute. The steps for using it are in Sign users in to the support chat.

#Import your Intercom conversations

Copies up to 24 months of your Intercom conversations into Support as tickets, with their original dates, so your team keeps the history and you can compare Revvly with Fin on them (Support, Compare with Intercom). Revvly only reads from Intercom and tells nobody about imported history. This is not the help-centre import on the Knowledge page, which brings in articles, not conversations.

1. Get an Intercom access token. You need to be an admin in Intercom.

1. In Intercom, open Settings, then Integrations, then Developer Hub.
2. Select New app, name it something like “Revvly import”, choose the workspace you want to import from, and create it.
3. Open Authentication. Make sure the app can read conversations, read users and companies, and read admins, and save.
4. Copy the Access token. Treat it like a password: it reads your whole inbox.

2. Start the import.

1. Paste the token into Intercom access token.
2. Choose where your workspace is hosted: Europe if your Intercom address starts with app.eu.intercom.com, Australia for app.au.intercom.com, otherwise United States.
3. Choose how far back to import (at most 24 months), then select Start import.

The import runs in the background and survives restarts; the page shows its progress. Revvly encrypts the token, uses it for this import only and discards it when the import ends, so you can delete the app in Intercom afterwards. When it finishes, compare the number of conversations it saw with Intercom’s own count for the same period, and open the failures list if there is one: each line is a conversation and the reason it could not be copied. Running the import again is safe: conversations already imported are skipped and only new messages are added. Run it once more if your conversations were imported before 15 October 2026, so Fin’s outcome is kept for the comparison with Intercom.

#Go-live checklist

1. Support is on, and everyone who should work tickets is a member of the workspace.
2. Every kind of customer who should see different articles has a role whose rules match the role value or attributes your system sends, and plans are spelled the way your system sends them.
3. Ticket types and statuses match how you work, including which statuses are Pending.
4. Knowledge sources are added, read and healthy, nothing is waiting under Needs a decision, and the Knowledge badge in the sidebar is clear. See Build the knowledge base.
5. A secret key exists and your backend creates tokens only for the signed-in user. See Sign users in to the support chat.
6. The widget is on your site and every production address is in Widget allowed origins. See Add a support chat to your app.
7. Guidelines tell the AI the tone for each role, the context your articles leave out, and which questions to leave to your team. See Write guidelines for the support AI.
8. You decided on auto-close, the AI switch and a daily spending cap, and set the AI switch on the types where you want it.
9. Agents checked their notification preferences, and clients can turn off emails about unread replies.
10. You tried each role in the sandbox and read the answers as that customer. See the sandbox.

Related

• Work the support inbox ›
• Build the knowledge base the AI answers from ›
• How the AI first line works ›
• Support chat API reference ›