From prototype to request portal: what to agree before development

Follow one request through to its outcome

Consider a fictional office. Someone reports a broken projector, a coordinator assigns the work and a technician records the outcome. The requester needs to know who is handling it and what happened. Write that sequence before discussing filters, dashboards or notifications.

In this example, the initial request needs a location, an item and a description of the problem. The coordinator sets the priority and assigns responsibility. Include incomplete reports: who asks for clarification, who answers and where that answer remains visible. A request with missing information needs an agreed route forward.

Decide who can see and change each request

Signing in identifies a user; it does not decide which requests they may read or change. OWASP recommends checking permissions for each operation, including in the system receiving it. Hiding a button in the interface is insufficient.

The following matrix is a proposal for this example, to adapt to your organisation. Also ask how access is granted and revoked.

Agree what “saved” means

After submission, the request should have a recognisable reference and remain available when the page is reopened. Ask the developer to demonstrate this with two test accounts: the coordinator must see the requester’s item within the correct scope.

Decide which changes belong in the history, such as assignment, status, author and time. When two people have the same request open, an update based on old information needs an agreed outcome, such as a warning followed by reloading the item. It should not silently erase an earlier decision. Specify this behaviour alongside the normal path.

Help people recover from errors

A missing required field needs a text explanation identifying the problem. The W3C criterion on error identification calls for the affected item to be identified and the error described in text. Colour alone does not communicate that information.

An interrupted submission needs a different response. The person must be able to distinguish a saved request, an unsuccessful submission and an outcome that still needs checking. Agree how they recover without creating duplicates. Test an expired session too: the person should understand what can be recovered and whether they need to sign in again.

Turn the demonstration into acceptance checks

Prepare synthetic requests and name someone on your team to check the delivery. For each test, write the starting situation, the action and the expected result. For the office example, include:

• Submit a request, reopen the page and find the saved item.
• Assign the work, record the intervention and show the outcome to the requester.
• Use another account to confirm that requests outside its scope remain inaccessible.
• Retry an interrupted submission and check that only one request exists.
• Correct a missing field without losing information already entered.

Include the boundaries in the proposal

Attachments, email alerts, connections to other systems and working without a network each need their own decisions. Include them when they serve the first workflow. Ask the proposal to identify initial data, responsibilities, administration instructions and support after delivery. Bring Ospivia a process description and two example requests to discuss the scope.

Explore an example

ServiceBot illustrates a request workflow using synthetic data. This internal example helps discuss states and outcomes; it does not demonstrate a live customer portal or every function described here.

Technical references

• OWASP: authorisation and permission checks
• W3C: identifying input errors