Module M1
RunningCases and repair reports
Residents report a fault on their phone, pick a category, and answer whether you may enter with a master key. You get a queue with status, priority, assignment and a history nobody rewrites afterwards.
Wired end to end against a real database and in use in the product.
What shapes this module
The history is recorded, not inferred. Every event is written as its own line, nothing is overwritten, and a correction is another line. Each line carries whether the resident sees it: status changes do, assignments and internal notes do not — which of your handlers holds a case is your own planning, and a note is written for a colleague, which is exactly what makes it useful.
For residents
- Report a fault with a category, a description and master-key consent
- Your own cases with their status, without ringing to ask
- A history per case — the same lines the handler sees, minus the internal ones
- Email and SMS on every status change, in the language the resident chose
For the manager
- A queue filtered by status and priority, with the filter in the URL so a view can be saved
- Assignment to a handler
- Status transitions from a fixed model — the button only appears when the move is allowed, and the server checks it regardless
- Internal notes the resident never sees
- Case categories you name, order and retire yourselves
What you configure yourselves
- Categories: names in Swedish and English, ordering, and whether a category may be flagged urgent
Not built
Photos on a report are not built and wait on file storage. SLA per category and routing urgent cases to whoever is on call do not exist: who is on duty on a Tuesday in November is something you know and we cannot guess for you, so it becomes a setting before it becomes code.
Contact
Tell us how a repair report is handled with you today.
Write a few lines about the portfolio you manage and where the time goes today. We will reply with how that looks in the system, and book a call if it seems worthwhile.