Sixnix Desk

A multi-brand helpdesk with the engineering work built in.

Tickets, live chat and email at the front; an issue tracker, releases and repositories behind them; and the join between the two, several customers reporting one fault gather on one issue, and when it is fixed, one action answers all of them. Any number of brands share one install, each with its own departments, mail identity, knowledge and assistant.

This is the complete documentation. It is written for three people, and every page says at the top which one it is for:

• Running it: installing the desk on a server, connecting it to email and to a billing platform, and keeping it healthy.
• Working it: the agent’s day: tickets, chats, clients, the issue tracker.
• Building on it: the integration API, the Blesta module, automation keys and the sixnix-desk CLI.

Where to start

If you are	Start at
Installing the desk for the first time	Requirements → Preparing a server → Install → First run
Taking over an install somebody else made	How it fits together, then Settings
An agent on your first day	Tickets, Searching, Live chat
Connecting a billing platform	The integration API, The Blesta module
Pointing a script or an assistant at the issue tracker	Automation keys and the CLI

Everything, in order

Installing and running

• Requirements: what the server needs before you start.
• Preparing an AlmaLinux 10 server: the machine, a container engine and the firewall, from bare.
• Install: the container stack, certificates that fetch themselves, and a desk that works.
• Moving in from Blesta: bringing tickets, replies and notes out of Blesta’s Support Manager.
• First run: the brand, the departments, the first staff account, going live.
• Upgrading: pulling a new version, migrations, and the backup that comes first.
• Backups and restoring: what to keep, and how to come back from nothing.

How it is put together

• How it fits together: the pieces, and which of them can be switched off.
• Brands: the tenant boundary, and what each brand owns.
• Departments: where tickets land and who answers them.
• Staff and permissions: roles, brand and department access, what each can do.
• Clients: accounts, guests, contacts, and how the desk knows who somebody is.

Working the desk

• Tickets: the life of a ticket, replies, notes, drafts and everything on the pane.
• The dashboard: what is waiting, what is late, what the desk has been doing.
• Searching and the ticket list: the operators, the saved filters, the two search boxes.
• Stages: your own status names on top of the fixed states.
• Tags: labelling tickets, clients and issues.
• Canned responses: the answers you write once.
• Reminders and the calendar: nudges, snoozes, closures and iCal feeds.
• Satisfaction ratings: asking, and what the answers tell you.

Channels

• Email: mailboxes in, sending out, templates, threading and CC.
• Live chat: the widget, availability, nudges, the assistant, handovers.
• Visitor tracking: who is on the site, and where they are.
• Announcements: notices on the site, the widget and the ticket area.
• Status page and incidents: components, incidents, subscribers and the embed.
• Platform signals: what your billing system reports, and acting on it.
• Mass mail: lists, templates and throttled campaigns.

Automation and AI

• Automation rules: triggers, conditions, actions, shadow mode and backtesting.
• The AI assistant: providers, drafts, summaries, triage, the console, reply analysis.
• The knowledge base: sources, documents, and how answers use them.

The engineering side

• Issues and projects: the tracker, boards, checklists, links to tickets.
• Releases: versions, notes, and telling everybody who was waiting.
• Repositories: mirrors, commits that name an issue, browsing code.
• Bug and security reports: the public intake, verification and publishing.

Building on it

• The integration API: signed platform access to tickets, reports and status.
• The Blesta module: installing and configuring the first-party module.
• Writing a platform adapter: connecting something that is not Blesta.
• Automation keys and the sixnix-desk CLI: a key per project for scripts and assistants.

Operations

• sixnix-deskctl: maintenance from the command line, on either install path.
• Settings: everything desk-wide, and what belongs on a brand instead.
• Files and attachments: what may be attached, by whom, how large.
• Health and queues: the heartbeat, the workers, what to do when it goes quiet.
• Logs and retention: the audit trail, what is kept and for how long.
• Security: the isolation model, credentials, uploads, and what to check.
• Troubleshooting: the symptoms people report, and what they usually are.