What a portal is for
Most calls and emails a business receives are not really requests. They are questions about something the business already knows: where is my order, did you get my documents, when is the appointment, what do I owe. Each one costs a few minutes of somebody's time, and it arrives at the worst moment.
A good portal answers those questions before they are asked, and lets the customer do the simple things themselves, at eleven at night if that is when they think of it. The measure of success is not how it looks. It is how many of those calls stop.
Built for your customers, not your staff
The common mistake is to give clients a login to a cut-down version of the staff system. It never works well, because the two audiences want different things. Staff need density, shortcuts and everything at once. Customers want one clear thing to do next.
When we built Fortium for an accountancy practice, the client portal was a separate application with its own workflow, so clients were not navigating a system designed for accountants. It shares the same API and data as the staff dashboard, so what the client sees is always the current state, but the surface is built around what they came to do.
Wedshots takes the same approach for wedding photographers: the photographer gets a dashboard for bookings and delivery, and the couple gets galleries they can browse, favourite and share, with real-time chat between the two.
The awkward cases are the design
Anyone can build the happy path. The portal earns its keep in the cases your staff currently handle by email:
- Cancellations and changes, and what happens to anything already paid
- Part payments and refunds, and how they show up in your accounts
- Documents that arrive incomplete, and how the customer is told what is still missing
- A customer who belongs to several accounts, or an account with several people on it
We work through these in the scope, in writing, before the build. They are the difference between a portal that removes work and one that creates a new kind of it.
A portal is usually only as useful as what sits behind it. Taking a payment means talking to a payment provider; showing an invoice means reading it from your accounting system; confirming a booking may mean sending an email or a push notification. That is integration work, and it is scoped alongside the portal rather than discovered halfway through.
Who sees what
A portal puts your data on the open internet, so permissions are not a detail. Every record belongs to an account, every query is scoped to it, and a customer can see their own information and nothing else. Where it matters, that is covered by tests rather than trusted.
On Curbed, our fleet product, that runs to a four-tier role model, and the driver's side goes further in the other direction: scan the QR sticker in the car, photograph the damage, submit. No login flow, no app to install. Sometimes the right amount of portal is almost none.
When you do not need one
If your customers contact you a handful of times a year, a portal is a lot of software for a small problem. A good email address and a clear process will do. The same goes for a product you already pay for that has a customer area built in and does the job well enough. It is usually cheaper to live with its limits than to replace it.
Price
Fixed price, off a written scope, with engagements from £4,000. Most first builds of a real business system, portal included, land between £8,000 and £15,000. The code, hosting and accounts are set up in your name from the start.