BUILD
Customer portals and the integration question asked too late
5 min read
A customer portal is mostly an integration project wearing an interface, so whether each source system can be read and written to reliably should be verified before any design work begins.
Customer portals are easy to describe and that is the trap. Customers log in, see their orders, download their invoices, raise a request. Everyone can picture it, and the picture is all interface.
The interface is the small part. The portal shows data that lives in an accounting system, an ERP, a ticketing tool and possibly a spreadsheet, and the project is decided by how well those can be reached.
Establish feasibility per system, before design
For every system the portal needs, four questions, answered with evidence rather than a vendor's marketing page: is there an API, can we get credentials, is it documented, and what are the rate limits.
An hour spent making one real authenticated call to each system is worth more than a week of design, because it converts an assumption into a fact. The systems that fail this check reshape the project, and it is much cheaper to learn that before screens exist.
When there is no usable API
It happens often, particularly with older line-of-business systems and anything a vendor hosts without an integration offering. The options are worse than an API and they are not nothing.
- A scheduled export the source system can produce, imported on a cycle
- Direct database read access, where the vendor permits it and the schema is stable
- A middleware or integration platform that already supports the system
- Accepting a manual step, done deliberately and documented, rather than pretending otherwise
Live or cached, and say which
Reading from the source on every page view is simple and leaves the portal as slow and as available as the slowest system behind it. Caching makes it fast and introduces staleness, which has to be made visible rather than hidden.
Most portals end up mixed — cached for lists, live for anything a customer is about to act on. The decision should be explicit per data type and should be stated in the interface, because a customer looking at an invoice balance needs to know whether it is current.
Writing back is a different risk
Reading is forgiving. A failed read shows an error and the customer refreshes. Writing is not: a request submitted through the portal that silently fails to reach the source system is worse than no portal, because the customer believes it was received.
Anything that writes needs an idempotent operation, a visible confirmation that reflects the source system rather than the portal, and a reconciliation that catches the cases that fell between. This is where most of the engineering effort in a portal actually goes.
Scope version one by integration, not by feature
The instinct is to scope the first release by what customers want most. The more reliable approach is to scope it by which integrations are proven, and ship those.
A portal that shows three things from two solid systems, accurately and quickly, earns trust. One that shows ten things from six systems, two of which are intermittently wrong, teaches customers to ring instead — which was the cost the portal existed to remove.
Questions we get asked
How long does a customer portal take to build?
The interface is predictable; the integrations set the timeline. A portal over two well-documented APIs is a few months. One over a legacy system with no API can take considerably longer, and the honest estimate is not available until the feasibility checks are done.
Should we use an off-the-shelf portal product?
Worth checking first, particularly if your core system's vendor offers one, since it will integrate natively. Custom work earns its place when the portal has to span several systems, or when the experience is part of how you differentiate rather than a utility.
How should customers authenticate to a portal?
Prefer an established identity provider over building password handling yourself, and support multifactor from the start rather than adding it later. If customers already have credentials with you somewhere, work out early whether those can be reused, because asking people to maintain a second account suppresses adoption.