Support management for institutions
Every request has an owner, a deadline, and a record.
A request reaches your institution by chat on your website, by email, or from an officer at the desk. TaifaSupport gives it a number, assigns it to somebody by name, tracks it against a deadline, moves it up a tier when it stalls, and keeps what happened after it is answered.
Ministries, state departments, counties and agencies.
What it does
One request, from the first message to the record.
Support management is the ordinary work of a public office: something is asked for, somebody has to do it, and somebody has to be able to say later what was done. Each request becomes a numbered record, and every change to it is kept.
- 08:41 Raised
By the person, through the chat on the institution website. The page they were reading is attached to the request.
- 08:44 Assigned
To the Registry team, and then to the officer on duty, by name.
- 09:10 Answered
First reply, timed. The clock on the request started when it arrived, not when it was opened.
- 11:35 Escalated
Up a tier to the directorate. The deadline it was raised with does not move, so the wait cannot be reset by escalating it.
- 15:02 Resolved
The answer is written on the request, where the person and the auditor both read it.
None of those lines is written up afterwards. Each is recorded as it happens, against the officer who did it, so a question about this request a year from now has an answer that does not depend on anybody remembering.
Before the request
The officer can see the website while it is being read.
People arrive at an institution's website before they ever write to it. TaifaSupport shows who is on the site now, the pages they are reading and how long they have spent, and it carries that page onto the request when one is raised. That is why the first line of the register above already knows where the person was standing. An officer opening the chat is not starting with the question of which service this is about.
In an institution
It fits the chart you already have.
An institution is not a flat list of officers. There is a chart, people sit at named points on it, and work moves up it when it has to. TaifaSupport is shaped the same way, so the establishment is not flattened to fit the software.
- A ministry
- ICT
- eCitizen sign-in
- Portal faults
- Registration
- Titles
- Searches
- ICT
- Work goes to a queue, not a person
- A request is routed to a team: ICT, Registration, Billing, whatever the institution actually runs. An officer serves on as many queues as their job spans, and a queue that reaches nobody says so rather than quietly swallowing the request.
- The role names are yours
- Support Officer, Records Clerk, Assistant Director: the institution writes its own titles. Authority is compared by rank, so a role you invent lands in the right place without anything being rebuilt.
- Escalation moves the request, not the deadline
- A request that stalls goes up a tier to somebody more senior. It keeps the deadline it was raised with, so how long a person has really been waiting cannot be reset by passing the request on.
- Every change has an author
- Assignment, reply, escalation, resolution and closure are each written to the request with who did it and when. That record is the answer to an audit query, and it is not optional.
Where it runs
Where it runs, and who holds the data.
For a public body this is not a footnote, so it is not one here. There are two ways to run TaifaSupport, from one codebase, and both of them answer the question of whose hardware the records sit on before anyone has to ask it.
On the institution’s own servers
Installed behind your own network with Docker Compose: the application, PostgreSQL, Redis, and a model host in the same rack if you want the assistant. Nothing has to leave the building for the product to work.
On our cloud
We run it, update it and back it up, and the institution signs in. It is the same software as the self-hosted edition, with one institution to a tenant.
- The Data Protection Act 2019
- The product is built to it rather than audited against it afterwards. Consent is asked before a chat is opened with somebody, and personal data is collected because a piece of work needs it, not by habit.
- One institution cannot see another
- Every query carries the institution it belongs to, in the data layer. Another institution’s request is not hidden from a screen, it is never returned at all.
- No raw IP addresses are stored
- An address is read once to work out a coarse location and is then dropped. The location is what an officer actually needs; the address is only a liability to hold.
- The assistant is optional
- It can be switched off entirely, or pointed at a model running on the institution’s own hardware, in which case no text leaves the network to be answered.
The next step
See it running.
Tell us which institution you are with and what you would like to see, and we will arrange a demonstration around the work your officers actually do.