The context attaches itself
Name, address, role and job title, workspace, browser, time and the screen they came from. The person writes a subject and a message; the rest is already in the record.
All modules
Back office
Support
Someone at the school hits a bug, has a question or an idea. They write to us without leaving the panel, and the report lands in the Cerium operator's inbox with the full context, staying on the list until it is closed.
Open 1
Closed 4
Free of 20 19
TicketKindPriorityState
Jak dodać drugą salę? 18.09 questionnormal Closed
Uwaga w dzienniku nie zapisuje się 17.09 bugnormal Open
auto support · your tickets in this space
Support
What this module does
4
kinds: bug, question, idea, billing
20
open tickets per person, a code constant
2 MB
heaviest screenshot, outside school space
1
screenshot per ticket, paste it in
Your own reports at hand
Under the form sits the list of what this person has already sent, with its state. A report has two states and not one more: open or closed.
The reply comes by email
The operator answers at the reporter's address rather than in a panel thread, and closes the case only after replying. Closed reports leave the open list.
Priority follows the role
It is taken from the role at the moment of writing and shown in the email subject: a student reports at low priority, so staff matters are handled first.
Everyone working in the panel
Owner, methodologist, teacher and student all have the module by default. Each person can keep up to twenty open reports, and every closed one frees a slot.
Who sees what
A module is a permission, and which records may be touched is settled on write, not in the menu.
| Role | Sees | Changes |
|---|---|---|
| Owner | Their own tickets. Nobody in the school sees anyone else's, not even them. | Files a ticket and attaches a screenshot. The Cerium operator closes it. |
| Methodologist | The same: their own list and nothing beyond it. | As much as the owner, and at the same priority. |
| Teacher | Their own tickets; the module comes by default, like the rest of the team. | Files tickets at the ordinary staff priority. |
| Student | Their own tickets - they get the screen, because bugs happen to them too. | Files tickets, but at low priority, and that comes from the role. |
The details nobody asks about during a demo
The things that only surface in the third week of working with the module.
What this module does not do
- a conversation in the panel - the answer goes by mail, and a ticket has two states
- attachments beyond one screenshot - the rest travels in the mail reply
- a hand-picked priority - the role decides, because everyone would tick “urgent”
- an answer base, or a message announcing that a case has been closed
Everything the reporter would otherwise retype: name and address, role and position, the space together with its key, the screen they came to Support from, the browser and the time. The screen attaches itself on navigation, because “/support” as the place where it happened says nothing. The party details sit in the row as a snapshot, so after a school renames itself the ticket still says what the mail said.
Three ways: a button, a file dropped on the field, or a paste from the clipboard. The third matters most, because a screenshot is taken with PrintScreen and lands in the clipboard, not in a file. The browser shrinks it, not the server: the longest edge drops to 1600 px, the format is WEBP, and quality walks down a ladder that stops below 500 KB - light, but legible, because an unreadable error message is no report.
No, and that is a decision rather than an oversight: a screenshot is a parcel sent to us, not a file on the school's shelf, so it stays out of the storage limit. Two other things bound it: one image of up to 2 MB per ticket, and a window of one hour from sending it. The storage key is derived from the ticket itself, so deleting the ticket takes the bytes with it, even when the upload was never confirmed.
Nobody - the role at the moment of filing decides. School staff write at ordinary priority, a student at low, because they do not run the school and their case waits behind the team's. The priority appears in the subject line of the mail we receive and in the operator's column. There is no manual choice, for a simple reason: everyone would tick “urgent”, and then priority means nothing.
By mail, at the reporter's address - it stands as the reply-to address in the message we receive, and the operator has an “Answer by e-mail” button in the drawer. There is no thread in the panel, and a ticket has exactly two states: open and closed. The operator closes it after answering, so a second message about the closing alone would only repeat itself.
No. The list under the form shows only the tickets of that one person in that one space, and this holds for every role. The whole picture belongs to the Cerium operator, who is the other side here: the same “/support” route draws them a table of the entire installation, with the scope in the address, a drawer of content and a close button, instead of a form.
Twenty open ones per person, and every ticket the operator closes frees a slot. That is a constant in the code, not a limit the operator sets per school - a ticket is not data a school multiplies, and its price is our work rather than room in a database. Beyond that nothing is capped: neither tickets per month, nor a description below ten thousand characters.
No. The only recipient is the Cerium team, and only one way. Mail inside a school is Messages, staff conversation is Chat, and the contact form on the Cerium site is a third thing entirely: there a stranger writes without an account, while here every row carries a session, a space and a role.
See Cerium from the inside.
14 days on your groups and instalments. No card, no strings.