Customer portals and internal tools
A portal can give customers a place to submit requests, upload documents and check progress. An internal tool can give staff a queue for reviewing the same requests, applying the organisation’s rules and sending them to the right team. The screens follow the work people need to do. At the start of a project, identify where the work takes place today, which steps already run in another system and where staff have to copy data between tools.
For a service with several types of account, a role map defines who can start a request, approve it, reopen it or see its attachments. It also records who manages membership and what happens when a customer changes organisation. These decisions determine the shape of the interface and the checks the backend makes on every request.
Data ownership and integrations
Decide which system owns each important record. For example, the portal might own the notes and attachments for a support request, while an existing CRM owns the customer profile. An integration can connect the records using a stable identifier. Keeping ownership explicit lets the team decide where each correction should be made and whether a missing or unavailable external record should stop the work or leave it pending.
Existing data may include duplicate records, old status labels or missing fields. If migration is in scope, agree how to translate those values and set aside records that need a person’s decision. A sample import lets staff compare totals and inspect a few real workflow histories before the new system takes over.
Acceptance example for a request portal
Illustrative scenario. A customer submits a request with two attachments. The portal shows a reference and the request appears in the appropriate staff queue. If the connection drops while the request is being saved, reopening the portal either finds the saved request by its reference or restores the draft so the customer can submit it. Trying again produces a single entry in the queue.
A reviewer can ask for another document and record why the request is waiting. The customer can upload that document on a phone and see the request return to review. A user from a different organisation cannot open the request. If two reviewers try to update it at once, the application explains which change was saved and lets the other reviewer refresh the record.
Release and handover
Use the same acceptance checks with representative data before release. Review the first sign-in, the busiest workflow and the steps that staff use to correct mistakes. Agree who configures the application, who owns operational alerts and where to look for a failed import or a delayed notification. If the application replaces an existing tool, document the cutover point and the steps for restoring service if the first release needs to be reversed.