Customer portals · SOULTWARE LLC
When email is no longer a good way to update customers
Email is a reasonable way to answer a single question. It is a poor system of record when customers repeatedly ask for the same status, file, or next step.
The same questions come back every week
Count the messages that ask where something is, whether a file was received, or what the customer is supposed to do next. If staff answer those from memory or by searching an inbox, the customer is waiting on a person rather than on a record.
A portal is worth considering when those answers already exist inside the company and can be shown safely. It is not useful if the status is not maintained. A screen that says “in progress” without an owner will create a second place to send email.
A portal is a shared record, not a second website
The customer needs to sign in, see their own items, send the requested information, and read the current status. Marketing pages, blogs, and a general contact form belong on the company website. Mixing them into the portal makes both jobs less clear.
Access matters as much as the layout. One customer should not be able to open another customer’s documents. That rule has to be true for files and notes, not only for the list on the first screen.
Start with one job the customer already does
A first release can be narrow: submit a request, attach the files the team asked for, and see whether it is waiting, in review, or complete. Account settings and a long history can follow after the team uses the record every day.
Write the acceptance check from the customer’s side and the staff side. The customer can find yesterday’s request. The staff member can see the file without asking for it to be forwarded again.
Only offer self-service the team can support
A portal creates an expectation that the status is current. Someone inside the company has to update it, including when the work is stuck. If that will not happen, keep the update in a channel the team actually uses.
Soultware builds customer portals around that operational promise. The design starts from the requests, documents, and statuses customers already ask about.