Asking the School for Something
A broken projector, a box of markers, a hall for Saturday. Requests that have no record yet, raised by anybody — including the classroom teacher who holds no office — addressed to the office that answers that kind of ask, and closed by a signed memo the artisan can have checked without an account. Four request types, six registers cut by the module that raised them, and a decision route per type so a narrow grant stays narrow.
The asks that have nowhere to live
Most of what a school approves is a decision about a record that already exists: a refund of an invoice, a disposal of an asset, a leave request against a contract. Those stay where the record is, because an approver who cannot see the surrounding record is guessing. But a school also spends its week on asks with no record at all — the JSS 2A projector has died, we are out of whiteboard markers, the hall is needed on Saturday, release forty thousand naira for the inter-house sports. Nothing in the product could hold those, so they lived in WhatsApp and in somebody’s memory. This walkthrough follows one of them from a teacher who holds no office to the artisan who fixes the projector and gets paid on the strength of a memo he can verify himself.
On this page
Somebody with no office asks for something
The test for whether a request belongs here is simple and worth stating before any screen: does approving it CREATE something that does not yet exist? A repair, a purchase, a released sum, a booked hall — yes. A refund of invoice 4471 — no, that decides a record Finance already owns, and it stays there. Everything in this walkthrough is on the first side of that line, which is why none of it was absorbed from another module.
My requests
The staff portal’s own queue: what this person has asked the school for, and where each ask got to. A separate namespace from the school register rather than a filtered view of it — the server pins every read here to the caller whatever the client sends, so a teacher’s list cannot accidentally render rows the school-wide register fetched.
Raising one
The form, open. Four types, and the type decides both the shape of the form and the office it will reach: Maintenance goes to the Facilities Officer, Purchase to the Store Keeper, Funds to the Bursar, Booking back to Facilities. Choosing the type is the only routing decision anybody makes, and it is made by the person who knows least about the school’s org chart.
Ready to run your school on this?
Every screen in “Somebody with no office asks for something” is the live product, not a mockup. Create your school account, or have us walk you through it on a call.
It lands on an office, not on a person
Nothing here is assigned to an individual, and there is deliberately no field that could be. A request is addressed to an OFFICE; whoever holds that office today sees it, and whoever inherits it tomorrow inherits the pending work with it. That is the same routing every other approval in the product already uses — separation of duties, conflicted-office escalation, the visibility predicate — reused rather than reimplemented.
All requests
The complete register, ungated. It is first and it is where somebody holding a single decision grant actually works, because their own queue is spread thin across the source tabs by design — one hostel purchase here, one library repair there.
One request, and the decision
The projector, in full: who raised it and what office they held at the time (none — she is a classroom teacher, and refusing her would have defeated the intake), what they asked for, and the two buttons that answer it. Approving issues the memo; rejecting requires a reason, because a refusal nobody can act on is not an answer.
See this on your own school’s data.
Every screen in “It lands on an office, not on a person” is the live product, not a mockup. Create your school account, or have us walk you through it on a call.
Cut by the module that raised it
The registers are grouped by SOURCE, not by type, because “what is outstanding for the hostel?” is the question a school actually asks and “show me every booking” is not. Type stays a column and a filter on all six. Each register is gated on its module’s entitlement, so a school with no boarding house never meets a Hostel tab — an empty table with a confusing name is worse than no tab at all.
General
The catch-all, and the busiest — the only register that is not a purchasable module. A classroom projector belongs to no module, and it was the single most common request the product had nowhere to put.
Inventory
Requests the store room’s own work raised. This is the register that receives a work order automatically: when the holder of a school laptop reports it damaged or faulty, that report raises a Maintenance request here addressed to the Facilities Officer — with the custodianship row named, so the Facilities Officer knows which laptop.
Library
Shelving, repairs, and the purchases a librarian raises that are not book acquisitions. Acquisitions have their own register in the Library module and stayed there — they decide a record that already exists.
Hostel
Boarding-house asks. Note what is NOT here: a broken window in Unity House is a hostel maintenance request, which the Hostel module already owns against a specific room. Maintenance in this module targets the Facilities Officer and never the Warden, who is scoped to one hostel — routing here would force every request to name a boarding house.
Health Clinic
The sick bay’s own asks — restocking, equipment, a released sum for an emergency. The nurse raises them; the Bursar and the Store Keeper answer them, which is exactly the separation a clinic budget needs.
School Store
The shop’s restocking and equipment asks. Six registers, one table, one endpoint set — the source travels as a query argument and the cache is keyed by it, so the hostel’s rows and the store’s rows were already separate without six copies of the same page.
Set this up for your team.
Every screen in “Cut by the module that raised it” is the live product, not a mockup. Create your school account, or have us walk you through it on a call.
And then it leaves the building
This is the only workflow in the product that ends outside it. An approved request issues a signed memo — a frozen PDF carrying the asker’s signature and the approver’s — and the person who acts on it is an artisan or a supplier with no account and no reason to have one. The memo is rendered ONCE, at approval, and never re-rendered: a school that changes its letterhead next term must not change the bytes of a document somebody already signed.
Checking that the paper is genuine
A code printed on the memo, typed into a public page — or followed as the link the memo itself prints. The answer is deliberately thin: nothing here is anything the holder cannot already read off the sheet in their hand. The value is that the system confirms it rather than the paper asserting it.
Ready to run your school on this?
Every screen in “And then it leaves the building” is the live product, not a mockup. Create your school account, or have us walk you through it on a call.
Run your whole school on one connected platform
Start with the base package, switch on the modules you need, and give every parent, student and staff member a single place to log in.