Assistant functions and permissions

Agents configure the organization's virtual team on Assistant, under Assistants. Every assistant has a name, picture, role, specialty and one function. The team shares Chat's provider and privacy rules; a per-assistant model override uses the same provider and key. Connect models before expecting live model work.

Add, edit, reorder or remove an assistant

1. Select Add an assistant, enter the requested identity fields and select Add to the team.
2. Select Edit on its card. Set Name (up to 40 characters), Role (a short display title), Picture, Function and Specialty. Specialty supplements shared behavior and privacy rules; it cannot override them.
3. For Front line, choose Takes these Systems first and Knowledge base categories it prefers. For background functions, configure their settings as described below.
4. Choose Model, or leave The organization's chat model. Choose a model actually available under the current provider.
5. Select Save [name]. Not saved yet means controls have not been persisted. Cancel discards unsaved form changes.
6. Use Move [name] up/down to change team order. Use the On/Off switch to enable or disable its function; this switch saves immediately.
7. To delete a member, select Remove inside Edit and read the confirmation. Existing ticket conversations stay; a later assistant turn can use another enabled member.

With a Chat provider connected, the last enabled Front line assistant cannot be switched off or removed; add or enable another first. Background functions cannot be ticket assignees. Front line members are the conversational assignees. Switching a function changes the applicable settings and defaults, so review them before saving.

Front line

Front line talks to requesters, troubleshoots, searches appropriate knowledge, can arrange live sessions and hands off to human support. Takes these Systems first guides routing when a ticket goes to any assistant; otherwise the enabled Front line team takes work in turn. Category preferences prioritize knowledge rather than granting new access.

On Assistant, Always hand straight to a person controls the organization's human-only systems. Configure these alongside the team; specialist preferences do not override human-only handling. Employees can request a person and agents can take over a ticket. See Routing and assignment.

After enabling a member, verify an authorized representative ticket: correct routing, actual cited articles, appropriate troubleshooting and successful human handoff. Do not assume a plausible response solved the employee's problem.

Knowledge writer

The writer reads Completed tickets with Resolution Details, using IT's definition and fix rather than the employee's whole conversation. It considers tickets not already processed or linked to an article, newest first. It can group related fixes into a new draft or propose an improvement to a published article. Names and contact details are removed before model use and drafts are checked again.

1. Set How far back to read: All finished tickets, The last 12 months, The last 6 months, The last 3 months or The last month.
2. Set Daily limit of model calls and Runs. Defaults are 50 calls and Every night at 2:00 (UTC).
3. Save, then select Run now for an initial supervised run.
4. Read its outcome: tickets read, articles drafted, edits proposed and calls used. No finished tickets to read can be a correct result when eligible tickets have already been processed.
5. Open Knowledge base → Drafts for review. Inspect the sources and procedure, edit a new draft when necessary, and Approve and publish, Approve the edit or Reject.

The writer never publishes without review. Fixes that need more supporting examples can wait for a later run. Review the actual drafted text for accuracy and sensitive details before approval.

Queue manager

All its permissions start off. Ticking a permission authorizes only that action; model confidence and ticket eligibility still determine whether it occurs.

Default budget is 100 model calls per day and schedule Every 15 minutes. Save before Run now. Review queue suggestions and Function log, then inspect linked tickets. Accepting or dismissing a suggestion is separate from allowing the function to suggest it.

Scheduler

The Scheduler works waiting tickets in the background; it is not an assignee. Its permission is Offer a live session in the thread to people whose open ticket has waited longer than the hours set below for a reply from IT.

1. Have participating agents save My live support hours first.
2. Enable that permission and set After … hours waiting for a reply; default 24.
3. Set the daily budget (default 50) and schedule (default Every hour), then save.
4. Use Run now and inspect tickets considered, offers made and calls used. Eligible tickets need a requester in the directory and actual available slots. An existing recorded offer can prevent a repeated offer.
5. Verify an offer's time, timezone and agent. The employee selects a slot before a booking is created. The server rechecks availability at booking.

Schedules, budgets and manual runs

Schedules are Every 15 minutes, Every hour, Every 6 hours, Every night at 2:00 and Only when you press Run now. The nightly time and displayed next-run convention are UTC, not the browser's local timezone. Daily usage also follows UTC.

The daily model-call limit must be a whole number from 1 to 100,000. Decision calls and writing can both consume a background member's allowance. When the limit is reached, the run stops and reports it; eligible remaining work can continue on a later run after the allowance resets. This is a call limit, not a fixed money budget.

Run now is disabled while the form contains unsaved edits. Save first, then run. A run that makes no change is not necessarily a failure: inspect permission state, ticket eligibility, confidence, availability, budget and the returned explanation. Manual runs can consume provider resources and make authorized real changes.

Function log and Undo

Within the card's Edit view, Function log lists times, action types, outcomes and links. Initially ten lines appear; Show … more expands the list. Open linked tickets or articles to confirm the result. Decision lines can include the job, confidence, threshold and outcome.

Undo appears only when the server supports undoing that specific recorded change. Select it and read the outcome, then inspect the linked record. Some actions, such as posted session offers, have no undo control; an action permission's explanatory text should not be treated as a promise that every log row has Undo. Before using Undo, inspect the current ticket: restoring the earlier assignment or priority can overwrite a later manual change. Already-undone actions are refused. Undo is a specific reversal of the saved action, not a complete ticket-history rollback.