02 / CLIENT SELF-SERVICE
A next step
people can finish.
Build client-facing tasks around understandable requests, useful guidance, and a clear acknowledgement.
Choose a complete task
Self-service works best when a client can finish a bounded action without interpreting the internal structure of the business. Examples include confirming contact details, selecting an appointment preference, or responding to a document request. These are illustrative possibilities, not features of a live Bayl Harbor product.
A task needs an explicit start and finish. If staff must review the result, the interface should distinguish “received” from “approved.” That small wording choice helps prevent a client from assuming that a submission has completed a wider business process.
Ask for information in context
Explain why information is needed at the point where it is requested. A file request can name the expected document and acceptable alternatives. A date field can identify the relevant event. Clear context often removes more friction than reducing a form by one field.
Previously supplied information should be visible when it helps a client make a decision. Re-entering known details creates both effort and the possibility of conflicting versions. Whether an existing value can be edited or merely confirmed should reflect the actual service responsibility.
Make uncertainty recoverable
People may not have the requested information, may need another person to respond, or may discover that the request does not apply. A well-scoped task includes an honest route for these conditions. It should not force an invented answer simply to reach the next screen.
Help can be part of the interface without turning every step into a long explanation. Short examples, a meaningful “not available” option where appropriate, and a direct contact path can provide enough support. Actual submissions require a connected backend and agreed handling procedures.
Show what happens after completion
An acknowledgement should restate what was received, identify any follow-up, and explain where the client can find the record later. If the team cannot promise a response time, the interface should not manufacture one. A visible received date and a responsible channel are still useful.
Possible project outputs include task flows, responsive screens, validation behavior, and acceptance examples for ordinary and exceptional paths. Scope is agreed for each project. The aim is a task that a client can complete confidently and a service team can receive without reconstructing its meaning.