Client portals often begin with separate menu items that mirror database actions: “Report an issue” creates a ticket, while “Report status” displays replies. That separation is convenient in code, but customers see both as one task: describe a problem, then return to see what happened.
In the ParitLAB Client Portal, we combined these actions into one Support module. Its main view shows previous requests, status, date, related product and administrator replies. A “New report” button opens the submission form as an overlay, so the customer does not lose the context of their existing history.
Why an overlay fits this task
Reporting an issue is a short action that begins from the existing list. A customer may need to check an earlier ticket title to avoid a duplicate, or confirm whether the problem already has an answer. Closing the overlay returns them to the same place and removes the need for two overlapping navigation destinations.
The overlay still has to behave as an accessible dialog. It needs a programmatic name, keyboard operation, an obvious close control and focus restoration to the opening button. On a small screen its contents must scroll without moving the page behind it.
Ask only for information the team needs
Our form asks for the software, a subject and problem details. The account and email already come from the authenticated session, so the customer does not enter them again. Guidance asks for the version, device and reproduction steps, while warning against sending passwords or secret keys.
Collecting less data improves both usability and safety. Support receives the details needed to reproduce a problem, while the customer is less likely to paste unnecessary personal information into a free-text field.
Translate states for the reader
The database keeps a small, stable set of values: new, in_progress and resolved. The Thai interface displays “received”, “in progress” and “resolved” in natural Thai, while the English interface uses its equivalent labels. Separating stored values from interface text allows copy changes and additional languages without rewriting historical records.
An administrator reply appears under the original ticket with a PARIT LAB label. The customer can distinguish their report from the support response and does not need to search a separate email conversation.
Access control and data integrity
Every customer-side query must use the user ID from the authenticated session. It must never trust a user ID submitted by the browser. Administrators can view the combined queue, while a customer receives only tickets that belong to their account. Creation uses a CSRF token, and the submitted project identifier is validated before storage.
When deploying the redesigned portal, we separated presentation changes from ticket data. The release did not recreate tables or migrate customer records unnecessarily. Before and after installation we compared counts for customers, licences, orders and support reports, and kept server-side file backups. A count check cannot prove every field is correct, but it is a useful guardrail against a destructive deployment mistake.
What to measure next
- Time from ticket creation to first reply.
- Share of reports missing a version or reproduction steps.
- Duplicate reports for the same issue.
- Tickets reopened after reaching resolved status.
- Cross-account access or authorization errors, which should remain zero.
The main lesson is that navigation should represent the customer's task rather than the database structure. Keeping submission, history, state and replies in one context makes the portal easier to understand while preserving a simple support model for administrators.