Core concepts

Nine words carry most of this product. Learn them once and the rest of the guides read easily.

Workspace

The workspace is the boundary around everything. Tickets, customers, teams, macros, SLA policies, channels, knowledge and settings all belong to exactly one workspace, and nothing crosses between them.

You belong to a workspace through a membership, and that membership carries your role. A person can belong to several workspaces with a different role in each.

Asking for something in another workspace does not tell you it exists. You get the same answer you would get for something that is not there at all. That is deliberate, and it is why a "not found" is sometimes a permission answer.

Ticket

A ticket is one piece of customer work. It carries a subject, a description, a status, a priority, the channel it came from, its tags, and the links to a customer, an assignee and a team.

Everything that has happened to it is on its timeline: customer messages, your replies, internal notes, status changes, priority changes, assignments, tag changes, customer changes, merges, reopens, CSAT requests and responses, SLA breaches, and logged time. Each entry records who did it and when.

Status

Three live statuses and five terminal ones.

Live statuses move between each other freely and can reach solved, closed or spam. The terminal ones are frozen: no new replies, no new notes, no ordinary status change. solved and closed can be reopened, which is the only way back. spam and merged cannot.

A ticket always tells you which statuses it can legally reach next, and an empty list means it is terminal.

Priority

urgent, high, normal or low. Priority sorts the queue and selects which SLA policy is stamped on the ticket.

Customer

The person a ticket belongs to. A customer record carries a display name, an email that is unique within the workspace, a company, a country and whatever metadata you attach.

Customers are created by hand, or by arrival: when a message comes in on a channel, the pipeline resolves who sent it and links the ticket to the matching customer. Email matches on the address.

A ticket does not have to have a customer. One opened by hand may have none.

Channel

A way for customers to reach you. Each channel is backed by an adapter, which is the code that understands one provider's messages.

Three separate facts describe a channel and none of them implies the others:

• Whether an adapter exists at all.
• Whether this workspace has connected it.
• Whether this workspace has switched it on.

A fourth fact matters most: whether the channel can send. Receiving and replying are separate capabilities, and a channel can do the first without the second. See Channels.

Every ticket records the channel it came from as its source, which is what the channel filters in the queue read.

Team

A named group of workspace members, used for routing. A ticket can carry a team, an individual assignee, both or neither.

Today a team does two things: it routes, and it decides who gets notified about an SLA breach on an unassigned ticket.

Macro

An ordered list of actions applied to a ticket in one step: post a reply or a note, set the status, set the priority, add a tag. Apply one by hand from the composer, or give it a trigger so it fires on ticket create, ticket update or both, against conditions you define.

SLA policy

A first-response target and a resolution target, per priority. When a ticket is created the enabled policy for its priority stamps two deadlines on it. Missing one flags the ticket and notifies whoever owns it.

An SLA policy here is a target you set for yourself. It is not a promise made to a customer, and nothing in the product tells a customer what it is.

Knowledge

Two different things wear this word.

Knowledge bases are collections of documents your AI agents search.

The help centre is a public site of articles your customers read, on your own domain.

They are separate systems with separate screens. See Knowledge and the help centre.

Roles

Four, cumulative: viewer, editor, admin, owner. Your role is read from your membership on every request, so a change takes effect on your next one.

For every helpdesk capability, admin and owner are identical. They differ only in workspace administration. See Members and roles.

Two kinds of credential

A person signs in and acts as themselves, with their live workspace role.

A program uses an API key, which acts as the admin who minted it, is bound to one workspace, and reaches only what its scopes name. A key with no scopes reaches nothing.

Both travel on the same Authorization: Bearer header, and the sk_zr_ prefix is what distinguishes a key. They are not interchangeable in what they reach. See API keys and the API reference.

Next

• Quickstart
• Working the queue