Reconnecting to the school network restored access. The requester confirmed the connection was stable.
Knowledge-base draftReconnecting to school Wi-Fi
Ready for review before publishing.
AI prepares the follow-up after a technician resolves the ticket.
Scroll to follow the workflow, or choose a stage above.01 / 04
The detail, when you need it.
How it works across your desk, what stays under your control, and where your data goes.
Briefing, related reports and page-aware answers
One page for what needs you, what the AI changed on its own overnight and what it spotted: a cluster of reports, a device that keeps coming back, a loan pool about to run short.
Every overnight change is listed with its reason and an Undo, or says why it cannot be undone.
Frustrated requesters and anything past its service target come first.
“What the assistant saved you” is an estimate from words read and written, and the card says so.
Ask “what does this person have on loan?” on a student’s page and the answer is about that student. Questions about their loans, devices, repairs and tickets are answered straight from the records, and the matching rows light up on the page with their reasons and dates.
A person who reports the same thing twice gets one ticket: a same-person duplicate within 48 hours can merge on its own, with a one-click unmerge.
When several people at one site report the same outage, Plugboard proposes one incident with the evidence. Accept it and the reports are grouped, a known issue is posted, and each requester is told once.
Repair outcomes and approved routine actions
Access requests arrive as a card that already knows the groups, the licences, the free seats and who approves.
Joiners, movers and leavers come from the student system as runbooks: disable, sign out, licences, groups, mailbox delegation, device and loan recovery. Each is previewed, approved with step-up and undoable. Nothing is deleted.
Device fixes for staff devices come from a catalogue. The AI suggests one, a person approves it, and your MDM runs it.
At lodgement, a likely-outcome card shows the probable result, days and cost range, drawn from your own repair history.
Cover agreements. A repair covered by the school’s insurance with its vendor never asks a family to approve or pay.
Replace device. Take the new device from stock or the loan already out, or record one on its way, and say what happens to the old one. The repair, both devices and the person’s history record it.
Tone, urgency and student safeguards
Each requester message is read for tone and urgency. The queue has a Tone column and a Frustrated requesters filter, and Briefing lists them. With no AI, a rules pass on chases, reopens and waiting time still gives a coarse read, labelled as rules.
Staff get an experience score: a 90-day summary of waits, reopens and satisfaction on the tickets they raised. It is a conversation starter for a manager, not a performance measure.
No profiles of students or parents
No per-person score is calculated or stored for a student or a parent. Their tickets carry a tone like anyone’s, because a frustrated ticket needs answering, and their experience appears only in school totals. Tone never changes a person’s account, access or charges. In auto mode it can raise a ticket’s priority one step, never to the top, and that can be undone.
What is in the release preview?
The 0.22 release preview extends AI across intake, routing, repair classification and resolution review.
These workflows are in preview, separate from the stable product. Availability depends on the release and the AI features your school enables.
Route to the right desk
Suggest the department and queue from the request, within the school’s access and routing rules.
Understand incoming work
Read email and Teams intake, suggest repair types and apply your school’s configured decision criteria.
Spot when the fix worked
Recognise a requester’s confirmation that the issue is resolved and prepare a review. A technician confirms the resolution; AI does not silently close the ticket.
Keep the queue focused
Distinguish acknowledgements and automatic replies from messages that need attention, and find related reports for review.
What runs automatically, and what needs approval?
The AI proposes. People and your records decide.
Labelled
Every AI value is marked
Anything the AI wrote or changed carries an AI mark and its reason. Undo is one click, and where something cannot be taken back, such as a device restart, it says so.
Modes
Off, shadow, suggest, auto
Set per feature. Shadow compares proposals with what staff actually did. Auto unlocks only after a proven accuracy record.
Identity
Never automatic
Identity actions always wait for a person, and joiner, mover and leaver runbooks need step-up approval.
API and MCP
Writes wait for a person
A write requested through an API key or MCP is held until someone with the right permissions approves it.
Activity log
Every call on record
Admin, AI activity lists every model call and suggestion, searchable and exportable. Calls are logged as counts, not prompt text.
Students and parents
No generated text reaches them
Students and parents get help articles found by search and translations a person has approved. Safeguarding words show the school’s own contact.
Where does AI run, and what leaves our school?
Your hosting region and your AI processing are separate answers. Here are both.
Managed AI
Open models that DigitalOcean serves itself: gpt-oss-120b, NVIDIA Nemotron 3 Ultra and BGE-M3. Processing is in the United States, whatever your hosting region. Names, emails, phone numbers and IDs are pseudonymised before every call, and DigitalOcean stores no inputs or outputs.
Self-hosted, local model
The bundled local model runs on your own server. The text stays on your network, and there is no AI sub-processor to disclose.
No AI
Switch AI off for the school, or run without an AI connector, and nothing is sent. The desk works as it did before, with rules-based triage.
You can also connect your own OpenAI, Anthropic or compatible account. That provider works under your contract, and pseudonymisation stays on by default.
What pseudonymisation does not catch: a description that identifies a student without naming them, such as “the kid in 9B with the red case”, or a name that is not on your roster. The data-processing page lists these gaps and the sub-processors.
Pricing and other questions
Is this a chatbot?
No. You can ask it questions, but most of the work is prepared in the background and shown where you already work: on the ticket, in the queue and in Briefing.
Does it act on its own?
Only where you set a feature to auto, and auto unlocks only after a proven accuracy record. Identity actions never run on their own, no reply goes to a requester without a person, and undo is offered where supported.
Do students or parents talk to the AI?
No. No generated text reaches a student or parent. They get help articles found by search, known issues and translations a person has approved.
What does it cost?
The plan includes 5,000 hosted AI calls a month. Above that, hosted calls are A$25 per 1,000. A local model or your own key costs nothing from us. See pricing.
What if we don’t want AI?
Turn it off for the school, or per feature. With no AI, the desk works as it did before, and nothing is sent anywhere.
See it on your own tickets.
Fifteen minutes on your queue, your student system and the work you would hand to the assistant first, with a 30-day trial to follow.