These cookies are required for the website to function properly. They ensure security, enable basic features like page navigation, and store user session data. You cannot disable these cookies.
Feature · Review
Example screen with sample data
Review
Make the supervisor decision explainable.
OverviewReview Decision Register×
Public Grievance System · Review
New
Review Decision Register
Review decisions
| Parent | Source revision | Decision | Decided at | Reason | Reviewer | |
|---|---|---|---|---|---|---|
| TCK-68391 | 620 | Approve | 20 Oct | Approve rd-327 | ||
| TCK-54939 | 390 | Return | 21 Oct | Reject rd-459 | ||
| TCK-19319 | 450 | Approve | 19 Oct | Return rd-718 | ||
| TCK-99716 | 460 | Return | 10 Oct | Approve rd-673 | ||
| TCK-46108 | 190 | Approve | 15 Oct | Reject rd-690 |
6 of 6 records
Approve rd-327Review decisions · RD-87835
ApproveParentTCK-68391
Source revision620
Decided at20 Oct
What you can do
Keep the working record clear
A Service Supervisor reviews a submitted grievance against its parent ticket and supporting evidence. The decision is recorded in review decisions with the source revision, decision, reason, time and named reviewer. This makes the outcome understandable to another supervisor or to the agent who must complete the follow-up.
Approval and rejection are human decisions. A returned case needs a clear reason so the agent knows what to correct. The supervisor’s review should refer to the submitted revision rather than a later edit. The stable operation key helps the team distinguish a retry of the same decision from a conflicting second instruction. A decision on a different parent must never be treated as a decision on this case.
How the work is organized
- Source. The supervisor opens the submitted case and its parent ticket at the recorded revision.
- Decision. Approval, rejection or return is recorded with a reason and named reviewer.
- Follow-up. The Service Agent reads that decision before completing or correcting the case.
A return asks for further work; it is not an approval. A changed case revision needs another deliberate review so the earlier decision remains attached to the material the supervisor actually saw.
What to agree during setup
Agree which supervisors can review each organization’s cases and how a reviewer is separated from the person who prepared the case. Require a useful reason for each decision. Decide how the agent receives a return or rejection and which changes require the case to be submitted again.
Check the handoff on an actual case
Submit one case with its evidence, then ask a supervisor to approve or reject it. Inspect the stored reviewer, reason, source revision and parent ticket. Retry the same command and verify that the decision is not duplicated. Edit the case and confirm that an earlier decision remains tied to the original revision.
Use the same sample to test a conflicting instruction and an authorized correction. The resulting record should tell the next handler what remains to do. Keep the earlier event or decision available when a case returns to work; otherwise the apparent current status can conceal an unresolved question. The supervisor should be able to identify the filing details and attachment used for the decision without relying on a separate message.
What your team sees
- Review Decision Register — Read the supervisor, reason and source revision for each decision.
- Submitted Cases — Find cases awaiting independent review.
Follow the work through
Follow complaint intake and case review to see how these records move between people. Use the data model when importing the first complaints and the roles page before granting access.
What it keeps track of
Data model- Review decisions
- Independent supervisor decisions on a frozen source revision, keyed for idempotent command replay.
- Grievance cases
- Domain grievance case raised against a ticket, carrying jurisdiction, filing date, priority and appeal reference.
- Tickets
- Intake and lifecycle record for each grievance ticket, with SLA dates, priority and revision guard.
- Team members
- Staff handling and reviewing grievances, resolved to an authenticated platform identity.
Who uses it
Permissions- Service Supervisor
- , Service Agent, Operations Manager.
Set up Public Grievance System your way.
Start free, then use Proto to change fields, steps and approvals before your team goes live.