A client portal gives customers a place to request interpreting services and follow what happens next. Its value depends on the handoff behind the screen: a usable request must reach the right coordinator, with enough context to review it. Before replacing an email habit with a portal, map the customer’s first visit, account creation, service request and confirmation. This guide explains what to include and how to launch with a manageable group of clients.
Separate a submitted request from a confirmed assignment
Write the customer journey in plain language: create an account, submit a request, wait for review, receive confirmation and follow changes. Decide what each status means before putting it on a screen. A request received by the agency does not necessarily mean an interpreter has accepted the work. Make that distinction visible near the action that creates the request.
For an illustrative example, ACME is a demo MigiHub client tenant. A consumer creating an account under ACME is entering that organization’s service environment. The account-creation recording on our product videos page shows the registration form; it ends before a successful submission or activation is demonstrated. Use that example to discuss your own registration requirements and approval process.
Collect a useful request without rebuilding the whole customer file
Start with the service language, date, time zone, expected duration, delivery mode and location or remote-meeting arrangements. Identify the person to contact if details change. Explain which information is required now and which details the agency will confirm later. A customer should not need to understand your internal scheduling vocabulary to ask for a service.
W3C’s forms guidance emphasizes meaningful labels, clear instructions and understandable feedback. Apply that to the entire request: tell the customer what failed, how to correct it and whether the request reached the agency. Test the experience on a phone and with keyboard navigation before inviting a wider audience.
Further reading: W3C: accessible forms guidance
Decide who can see and change each request
An individual consumer, a coordinator at a client organization and a billing contact may need different information. Make a small access map before configuration. Include who can submit, view a request, ask for a change and receive operational updates. Treat a change request as a workflow with an owner rather than assuming that every customer edit should immediately alter the schedule.
Use two test accounts from different customer organizations to check separation. Verify which details appear before confirmation and after cancellation. Review what happens when a contact leaves an organization. The goal is a portal that exposes the context each customer needs while keeping unrelated records out of view.
| Portal action | Decision to make |
|---|---|
| Create an account | Who reviews access, if review is required? |
| Submit a request | Which fields make it ready for coordination? |
| Follow progress | Which statuses are meaningful to the customer? |
| Ask for a change | Who checks the scheduling impact and responds? |
Run a pilot with real variations
Choose a small group that includes an individual consumer and an organizational customer. Walk through a straightforward request, missing information, a changed date and a cancellation. Ask each participant to explain what will happen next after every screen. Their answer is often more useful than a general satisfaction score.
Record requests that still require clarification, status questions arriving by email and time spent resolving access problems. Compare the same types of requests over a defined period; do not treat a different customer mix as proof of improvement. Keep a named support contact available during the pilot, then use the findings to refine instructions and access rules.
Connect the portal to the service your agency actually offers
MigiHub connects customer requests with booking and scheduling workflows. Its Customer Portal presents the language services your organization has configured, with request visibility and customer access defined around your process. The service catalogue and the interface language are separate settings: an interface preference does not determine the interpreting service requested.
Bring a sample customer journey to a demonstration, including account creation, a new request and a change after submission. Agree which information customers can see, which actions need review and how updates reach the people involved. A portal succeeds when the next operational step is as clear as the form itself.
Frequently asked questions
Does self-service booking mean an interpreter is confirmed immediately?
Not necessarily. Define the difference between a submitted request and a confirmed assignment, then make the review and confirmation steps explicit for customers.
Should an individual consumer and an organizational client have the same access?
Base access on the tasks and records each person needs. Test individual and organizational scenarios, including contacts who should not see one another’s requests.
Walk through your customer journey
Show us how an individual or organizational client should request a service, follow progress and ask for a change.
Book a demo
MigiHub Editorial Team
Practical guidance on operations, customer relationships and service-business management.
