1. Public Grievance System
  2. Features
  3. Responses
Feature · Responses

Responses

Record the actual answer and waiting time.

OverviewReopened Tickets
Public Grievance System · Responses

Reopened Tickets

Tickets

New
Record numberSubjectOwnerResolution due atStatus
TCK-94856Reopened tck-96012 OctReopened
TCK-17804Reopened tck-80007 OctReopened
TCK-47873Reopened tck-21115 OctReopened
TCK-46969Reopened tck-56411 OctReopened
TCK-32067Reopened tck-53625 OctReopened
6 of 6 records
Reopened tck-960Tickets · TCK-94856
Reopened
Resolution due at12 Oct
Example screen with sample data

What you can do

Keep the working record clear

A Service Agent answers a complainant after investigating a service interruption. The response belongs in ticket events with customer visibility and an occurrence time. The first actual response sets the date used to measure response time. An internal note may be useful to colleagues, but it does not count as an answer to the complainant.

When the agent needs more information, a pause event explains the reason and the ticket moves to waiting. Resume closes the interval before work continues. The sequence of events matters: an agent reading only the current state cannot tell how long the complaint waited or whether an earlier message reached the customer. A resolution event captures the outcome, and a resolved or closed state communicates the ticket’s current position.

How the work is organized

  • Answer. A customer-visible response event establishes the first actual response time.
  • Waiting. A pause event explains why the agent is waiting; a resume closes that interval.
  • Outcome. A resolution event carries the explanation behind the ticket’s resolved state.

The Service Agent can write private investigation notes between public answers. Those notes remain part of the work history, but they must not advance the first-response measure.

What to agree during setup

Agree what counts as a customer response, which event visibility is appropriate, and how the service calendar handles pauses. Review the wording and audience of any shared message before it is recorded. If an external channel carries the response, configure that connection and decide which provider acknowledgment establishes delivery.

Check the handoff on an actual case

Use a real sample with a public response, an internal note, a pause and a resume. Check that only the customer response establishes the first response date. Inspect the event order and the due date before resolving the ticket. Ask another agent to reconstruct the handoff from those records.

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. For a resident awaiting an update, compare the visible answer with the actual event time before calling the response complete.

What your team sees

  • Waiting Tickets — Find complaints awaiting information while retaining their owners.
  • Resolved Tickets — Check the outcome event and resolution time for completed service work.

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
Tickets
Intake and lifecycle record for each grievance ticket, with SLA dates, priority and revision guard.
Ticket events
Chronological events appended to a ticket: responses, notes, pauses, escalations and resolutions.
Customers
Complainants and affected parties who file grievances, with service address and eligibility note.

Who uses it

Permissions
Service Agent
, Operations Manager, Service Supervisor.

Set up Public Grievance System your way.

Start free, then use Proto to change fields, steps and approvals before your team goes live.

How to get started