Automation you can read.
AI that earns its place.

One builder for automation across the whole desk: tickets, repairs, loans, stock, visitors, kiosks, devices, knowledge and people, and the systems you connect.

• When. A ticket or repair arrives or changes, a person joins, moves or leaves, someone asks for access, a schedule comes round, another app calls in, or a connected system raises an event such as a security alert.
• Then. Change records, send messages, ask for approval, hand a task to a technician, wait, branch, decide, write with AI, repeat for each item, or call another flow.
• People flows. Joiners and leavers built from your account templates: Active Directory, a directory sync, licences and groups, with one go-ahead and step-up, and an undo that turns accounts off and never deletes them.
• Privileged access. Entra PIM roles activated by the person themselves, and just-in-time admin inside Plugboard that someone else approves and that ends on time.
• Approvals anywhere. Put an approval in front of any action. A flow can also offer itself on a ticket, repair or person, as a card a technician runs, sends for approval or dismisses.
• Other platforms. Hand a step to Power Automate, Zapier, Make or n8n through a signed connection, and start a flow from another app through its own hook.

A decision is a typed question with a closed set of answers: yes or no, one of a list, or a score. The answer chooses a lane in the flow. It never chooses who or what a step changes.

• Suggest first. Each answer is shown to a person, who confirms it or picks another. Only those human answers count toward the question’s record.
• Earned, per question and per model. A question acts on its own only after your people have agreed with enough of its answers, and only if your school allows it. A few corrections send it back to suggest.
• A fallback that always works. A condition written in words also has a keyword or field rule. With AI off, or no answer, the rule decides or a person does.
• Your choice of model. Decisions come from your AI provider, or from a dedicated decision model: Laya on a self-hosted server, or TypeSafe Jev on your own TypeSafe account. Decision text is always pseudonymised.

Sorting incoming tickets, sending them to the right queue, resolving on the spot, suggesting a device fix and spotting access requests run as system flows. Open one to see what it does, narrow it to one desk, or turn it off.

• Each keeps its own mode, threshold and track record, inside your daily limit on background AI calls.
• Routing and access requests learn from the answers your team corrected, inside your school only.
• Each week Plugboard points out work your team keeps doing by hand that could be a flow, from your records alone and with no AI calls.

Type what happened. The ticket and repair composers fill in the person, how it came in, the desk, the category, the priority and the device, and mark every field they filled so you can change it or undo it. They never write over a field you set.

• Resolved on the spot. When the words say the job is done, the ticket is raised already resolved, with the fix kept as a note.
• Polished wording. Turn quick notes into a clear description, and keep your own words if you prefer them.
• @-mentions. Mention a person, device, ticket or repair to link it. Mention a colleague in an internal note and they are told, if they can see the ticket.

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.

• Access requests arrive as a card that already knows the groups, the licences, the free seats and who approves.
• Joiners, movers and leavers run as people flows from the student system: accounts, licences, groups, mailbox delegation, and device and loan recovery. Each step is previewed, waits for a go-ahead with step-up, and can be undone. 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.

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.