A customer emails a document on Monday, calls for an update on Wednesday, and forwards an approval on Friday. Your team has everything it needs somewhere, but someone still has to assemble the conversation before the work can move.
A client portal gives customers a private place to exchange information and complete tasks with your business. It can bring requests, documents, progress updates, and approvals together. Whether it saves anyone time depends on what happens after a customer clicks Submit.
Before starting client portal development, I'd follow one ordinary request from the customer's first action to the employee who finishes the work. Pay attention to where someone has to chase a reply, find a missing file, or enter the same information again.
Start with the task customers keep calling about
Look through recent emails and support calls. What are people repeatedly asking for? A copy of a document? An update on a job? Confirmation that you received their paperwork?
Choose a task that happens often enough to justify another place for customers to sign in. Then describe what a successful visit looks like in one sentence: “A customer can submit a service request, attach photos, and see whether we need anything else.”
For example, imagine a commercial maintenance company whose customers manage several properties. A useful first portal might let a property manager report a problem, choose the right location, upload a photo, and follow the request. The maintenance team needs the matching work order and a way to ask for missing information.
Before drawing the screens, settle a few details. Can a customer request urgent work? Does submitting a request book an appointment? Can customers see every property their employer manages? A developer needs those answers to price and build the process.
Give each request a clear next step
“In progress” tells a customer very little if the request has been sitting there for a week.
Use statuses that explain what is happening and who needs to act. “Waiting for your approval” is useful when the customer can open the estimate and respond. “Scheduling visit” is useful when your team is actually arranging the appointment. Avoid promising a date your internal process cannot support.
Decide which internal notes belong in the portal. A technician's working notes, a private discussion about pricing, and a message intended for the customer serve different purposes. Give staff a clear way to distinguish them.
The portal should also confirm receipt. Show a reference number, the information submitted, and what happens next. If the work needs staff review, say so. A received request and an accepted booking are different events.
Notifications should lead people back to an action or a useful update. Agree which events deserve an email and who receives it. Keep private document contents out of notification messages when a sign-in link will do.
Plan access around customer organizations
A business customer may have several people using the portal. One reports problems, another approves spending, and a third needs invoices. They may work across different locations or projects.
Write down who can see and change each kind of record. Include your own staff, customer administrators, ordinary users, and anyone with temporary access. Decide who can invite a colleague and who verifies that an invitation belongs to the right customer organization.
Individual accounts make actions easier to trace than a shared customer login. Plan account recovery, the appropriate use of multifactor authentication, and what happens when an employee leaves. Removing access should not erase the history of work they approved.
These rules need enforcement by the application on every request, including document downloads. Removing a button from a page does not prevent someone from requesting the underlying record. OWASP's authorization guidance explains why sign-in and permission checks are separate responsibilities.
Before launch, test with separate customer organizations and different roles. Include attempts to open another customer's record through a copied link.
Decide what happens to documents
An upload button is a small part of document handling. Decide where a file belongs, who reviews it, and how the customer knows it was accepted or needs replacing.
If a customer uploads a revised document, should the earlier version remain available? Which version does an approval apply to? How long do you keep completed requests and their attachments? Establish those rules before a folder full of files becomes the only record of the exchange.
Include file type and size limits, checks on the actual file, appropriate malware scanning, and private storage with controlled downloads in the development scope. OWASP's file upload guidance describes the safeguards behind those requirements.
Make rejection messages useful. “This file exceeds the 20 MB limit; choose a smaller file” gives someone a way forward. An unexplained failed upload sends them back to email.
Make approvals specific
“Approve” needs an object. Is the customer accepting an estimate, confirming a design, authorizing a visit, or acknowledging receipt?
Show the material being approved and record who acted, when, and which version they saw. Decide what happens if the estimate changes afterward, an approval is withdrawn, or a customer asks someone else to decide.
For the maintenance company, a property manager might approve an estimate while an on-site contact can only request work. The portal must preserve that distinction even if both people can read the request.
If an action needs a particular signature process or legal effect, settle that requirement separately and choose an appropriate service. A timestamp beside a button does not establish every kind of agreement you might need.
Connect the portal to the records your team uses
A portal can create more work if employees have to copy every request into another application and manually update both systems.
Identify where each important record belongs. The service system might own work orders, accounting might own invoices, and the portal might own customer-submitted photos. Specify which information moves in each direction and whether customers can change it after submission.
Then follow a failure. Suppose the portal receives a request while the service system is unavailable. Does the customer see that it is waiting to be transferred? Who gets an alert? How does the team retry it without creating two work orders?
“Connect to our CRM” leaves these questions open. A useful integration requirement names the records, their identifiers, the allowed delay, and the person responsible when an update fails. Our systems integration service covers that work. If the connections and responsibilities are unclear, start with a workflow and integration assessment.
Try the whole task on a phone
Your customer may be reporting a problem from a loading dock, away from the desk where the portal looked good during a demonstration.
Try signing in, choosing a location, taking or attaching a photo, and submitting the request on a phone. Use ordinary records with long names and missing details. Check keyboard use and screen-reader feedback as well as the visual layout.
When something fails, preserve the information already entered and explain how to fix it. After success, give a clear confirmation. W3C's guidance on form notifications covers both error messages and confirmation of completion.
Give customers a visible route to help. A portal that blocks someone from reporting urgent work because they cannot recover an account needs a practical fallback.
A sensible first release
For our example, the first release could cover one complete service-request process: submit a request, attach photos, receive a reference, answer a follow-up, and check progress. Staff would have a working queue or an integration into their service system, along with the necessary access controls and support arrangements.
Invoices, online payments, live chat, and management reports could wait unless they are necessary to complete that process. Adding every feature customers might eventually want makes it harder to find out whether the main task works.
First check what your existing service or CRM software already offers. A configurable customer portal may handle the process adequately. Custom development becomes worth examining when the required workflow, customer access rules, or connections are difficult to support with an existing product. Our custom software vs. off-the-shelf guide discusses that decision in more detail.
Ask for a quote tied to a defined process and its exceptions. The number of pages alone says little about the cost of permissions, document handling, or integrations.
Decide who runs it after launch
Someone needs to handle invitations, account problems, failed notifications, and requests that stop moving. Someone also needs to maintain the software, monitor its connections, and test that backups can be restored.
Assign those responsibilities and include the cost in the plan. Your business should have an agreed path to its source code, hosting accounts, data, and documentation. Establish how you would export records or move support to another developer. Our application support and maintenance service covers the continuing technical work.
Start with a small group of customers and the employees who serve them. Watch them complete real tasks, then compare the result with the process you hoped to improve. Are requests arriving with the information staff need? Are customers finding their own updates? Are employees still copying information between systems?
If customers still call for updates, find out what the portal is failing to tell them. If staff still copy every request, revisit the connection to their working system. Fix those problems before adding another section to the menu.
Honor Tech builds custom web applications, including portals connected to existing business systems. Tell us what your customers need to do and where your team handles that work today.