First run

For whoever is running the desk. An hour, most of it waiting for DNS.

You have the desk running and an administrator account, made on the setup page the desk printed a link to, named in .env, or created with desk:admin. This page takes you from there to a desk that can take a ticket, send an email, and be handed to your team.

Work through it in order, later steps assume the earlier ones.

Go to your desk’s address and sign in. Then Settings, which is desk-wide and has a section for each concern:

This desk: what it calls itself and the address it lives at. Both come from the server’s configuration until you set them here.
Security: session length, two-factor and passkey policy, trusted devices, how long a device is remembered.
Email: the outgoing mode (see below), and how long inbound originals are kept.
Housekeeping: how long trashed tickets are kept before they go for good.
AI: provider keys, and which model the console runs on. Skip for now if you are not using AI.
Location and visitors: whether addresses can be placed on a map, and which addresses to leave out of visitor statistics (your own office, by default anything the staff app has been used from).

Everything here is desk-wide. Anything that differs per brand (sender addresses, tone, tags, knowledge) lives on the brand instead, which is the next step.

2. Make the first brand work

A brand is the tenant boundary: its own departments, email identity, clients, tags, knowledge and AI settings. A one-company desk has exactly one brand and can ignore that it is a concept at all.

Open Brands, edit the default one, and set:

General: name, colour and logo. The colour and logo appear on client emails, the widget and the ticket area, so a neutral desk becomes yours here.
Email: the from-name and from-address clients see. Send a test to yourself before going further.

If you have several companies, add the others now. Starting a new brand from an existing one copies whichever groups you tick (email settings, client settings, AI settings, departments, rules) which is much faster than doing it twice.

3. Departments

Tickets land in a department, and a department decides who is notified. Under the brand → Departments, create at least one (Support, Billing, Sales, whatever matches how you actually work).

For each one, the settings that matter on day one:

Who can pick it: client-selectable, or staff-only for internal queues.
Guests: whether somebody without an account may open a ticket in it.
Members: the staff who see and are notified about its tickets.
Opening hours: with a timezone, and an optional auto-reply when a ticket arrives out of hours.
Priorities: which ones a client may choose, the default, and optionally a warning shown when they pick one (“Urgent is for production outages”).
Custom fields: extra questions on the new-ticket form, if the department needs them.

4. Staff

Staff → add your team. Each person is an administrator or an agent:

An administrator sees and does everything, everywhere.
An agent is limited to the brands and departments they belong to, plus whatever per-agent permissions you tick: rules, canned responses, the client list, AI on tickets, the AI console.

Give each agent their brands and departments before you tell them to sign in, an agent belonging to nothing sees nothing, which looks like a broken install.

Signatures go on the person, and are appended to their customer-facing replies.

5. Outgoing email

Until you do this, the desk writes mail to a log file instead of sending it.

Settings → Email for the mode, then the brand’s Email tab for the identity. You can send through an SMTP relay, or through one of the brand’s own mailboxes once you have connected one (below). Send a test from the brand page and confirm it arrives, is from the right address, and looks like your company.

Then do the boring, important part: SPF, DKIM and DMARC for every brand’s from-address. The desk will happily send mail that goes straight to spam.

6. Incoming email

Optional, skip it if clients will only ever use a portal or the chat widget.

Under the brand → Mailboxes, connect an IMAP mailbox: a plain server with a password, or Microsoft 365 or Google by signing in (the brand registers its own OAuth client, because a tenant only authorises its own accounts). Then choose:

The default department for mail that names no other route.
Address routing: billing@ into Billing, and so on.
New tickets: whether a stranger writing in opens a ticket, or is politely declined.
What happens to the copy on the server: leave it, mark it read, move it, or delete it.

Once a brand reads a mailbox, its outgoing ticket emails gain a “reply above this line” marker and a token, and client replies thread back onto the ticket automatically. A sender address on its own never links a message to an account, see Email for why that matters.

7. Connect a platform (optional)

If your clients live in a billing system, connect it so the desk knows who they are: brand → API keys, then install the Blesta module or write an adapter for something else. Clients then reach the desk through their account area, and the desk can show services, invoices and standing beside the ticket.

Without a platform the desk works fine, clients arrive as guests through an emailed link, or you add client records yourself.

8. Check the plumbing

Before anybody else signs in:

docker compose ps           # seven services, all healthy
sixnix-deskctl workers      # the queue workers, one line each

In the desk, Settings → Health should show the heartbeat green. If it is not, the scheduler or the workers are not running, and nothing will be emailed, see Health and queues.

Open a test ticket as a client, answer it as an agent, and confirm the email arrives at both ends.

9. Before you hand it over

A short list, learned the hard way:

A new agent can see nothing until they belong to a brand and a department. Check one account.
Take a database snapshot now, and make sure the nightly backup runs, see Backups.
Turn on two-factor for administrators in Settings → Security.
Decide retention for trashed tickets, inbound originals and logs, rather than discovering the defaults in a year.
Check the file types each group may attach (Files and attachments); the defaults are deliberately narrow for clients.
If you are using AI, set the per-brand tone and knowledge before switching on anything customer-facing, and start with drafts (suggested replies) rather than automatic triage.

Where next

Tickets for the agents’ side.
Settings for the full list of what can be changed and where.
Upgrading before you deploy the next version.