Showing request status to the person who submitted it

Show submitters what is known about their request, what the current state means and whether they must act. A label such as Open gives little guidance alone. A useful view shows the request ID, status, when that status last changed and the next expected step.

Translate internal states into useful updates

An internal queue may distinguish assignment, scheduling and review. The submitter needs the distinctions that change their understanding or action. For a facilities request, a compact view might use Received, We need more information, Being handled and Closed. Define how each displayed label maps to the underlying workflow.

Add a sentence where a label is vague. “We need more information — please confirm the room number” gives a clear task. “Being handled” may name the responsible team if that helps, without promising a completion time the team has not set. Show Closed only when the recorded outcome meets the closure rule.

Request Status Journey for Submitters

Distinguish an update from a confirmed save

After submission, show a request ID when the shared record is confirmed. If the chosen app can queue a change locally, tell the person it is pending and provide a way to check whether it reached the team. A failed or uncertain write should not produce an unqualified “received” message or an automatic invitation to submit again.

For later changes, show when the stored status was last updated. If the app cannot refresh, say that the displayed information may be old; a last-updated time is not proof that the screen has just checked the source. If an email or chat alert is sent, direct people to the request record for the current state.

Key Status Indicators for Request Visibility

Say who acts next

For each displayed status, write what happened, who acts next and what the submitter can do. Some states need no action from them. When an outcome is uncertain, give them a way to look up the existing request or contact the team before resubmitting.

If a request is declined, give an appropriate public reason and a correction or review route where the business process allows one. Keep sensitive internal notes in fields with the appropriate access rule.

Check access and accessibility

A submitter should see only requests they are entitled to view. A page filter helps presentation, but the chosen app's record and data access rules must also cover other available routes. With fictional accounts, try another person's request ID, search and export where those routes exist.

Use text to convey status, even if colour also helps. In a web interface, a newly displayed success, error or progress message that does not take focus should be detectable by assistive technology. A static request-status field and a newly announced interface message are different cases.

Before release, show intended users fictional requests in each state. Ask what they think happened and what they would do next. Compare their answers with the workflow rules, then inspect the saved status and submitter view under an ordinary account.

Using Colour vs Text for Status Visibility