Customer or dealer portal: build vs. buy, and what to scope first

Start with the jobs outside users actually do

Portal projects drift when they start from a feature list. Start instead from the requests your customer service, inside sales and dealer support staff handle every week, and count them. The busiest few are the first release.

Two numbers make the case for leadership and set the target for the build: how many of each request arrive per week, and how long each takes your staff to answer. Measure them before the project starts, so you can show the change afterward.

Three routes: product, module or custom

The choice isn't only build or buy. Many business systems, including CRM, service management and some finance systems, offer a customer or partner portal as a module or add-on. Check what you already own before comparing anything else.

Signals that point one way or the other

• Where the data lives. If the answers to your top jobs come from one system that already has a portal module, start there. If they come from three systems, the real work is integration, and a module in one of them won't remove it.
• How users are licensed. External-user pricing varies widely by product, for example per named user, per login or per active user each month. A dealer network where each dealer has several occasional users can cost far more than the demo suggests. Ask every vendor to price your realistic user count in year three, and to define exactly what counts as a user.
• How much the portal is your brand. For some companies the dealer portal is part of how they compete: fast quotes, easy warranty claims, good documentation. That weighs toward more control over design and workflow.
• Who changes it. Price lists, documents and announcements change weekly. Whatever you choose, business staff should be able to update content without a developer or a vendor ticket.
• What security review expects. A system reachable from the internet with outside users gets more scrutiny than an internal app. Find out early what your security team requires, such as multi-factor authentication, penetration testing and logging, and check each route against it. Our guide to security testing a custom web or mobile app before launch covers planning that testing.

Scope the first release around two or three jobs

A first release that does a few jobs well gets used, and usage is what justifies the second release. A first release that does everything a little is harder to launch, harder to support and easier for customers to ignore.

1. 1Pick the busiest read-only job first. Order status or document download usually carries the most volume and the least risk, because nothing is written back to your systems.
2. 2Add one request workflow. A return, warranty claim or service request that lands in a queue your staff already work, replacing a form that gets retyped.
3. 3Include account administration. Customer and dealer administrators add and remove their own users. It sounds like a later feature, but without it your staff become the portal's help desk.
4. 4Choose a small group of pilot accounts. A handful of friendly customers or dealers who will use it and tell you what's wrong, before it's announced to everyone.
5. 5Write down what's out. Online ordering, payments, quoting and configuration are each substantial projects. Name them as later phases so they don't sneak into the first one.

Sign-in and accounts for people outside the company

Staff sign in through your workforce identity provider. Customers and dealers usually shouldn't: they aren't your employees, you don't manage their devices, and your directory shouldn't fill up with thousands of outside accounts that nobody reviews. Most portals use a separate customer identity service, such as Amazon Cognito or your identity provider's offering for external users, with the same OpenID Connect sign-in patterns that internal apps use.

• Model companies, not just people. A user belongs to an account (the customer or dealer), and roles apply within that account: administrator, buyer, accounts payable, service technician. One person may belong to more than one account, for example at a dealer group.
• Invite, don't self-register. New users are invited by your staff or by their own administrator, and tied to the right account on first sign-in. Open registration invites people to guess their way into someone else's data.
• Delegate administration. Each customer or dealer administrator manages their own users. When someone leaves the dealer, the dealer removes them, and the portal doesn't depend on anyone remembering to tell you.
• Require multi-factor authentication at least for administrators and anyone who can see pricing or financial documents, and support password resets without a phone call.
• Offer single sign-on for large accounts later. A big customer may want its staff to sign in with their own company identity provider. Choose an identity service that supports federation so that can be added per account without a redesign.
• Plan offboarding for whole accounts. When a dealer relationship ends, one action should disable every user on that account.

Our guide to single sign-on and least privilege for internal apps covers roles, permission matrices and the staff side of the portal, where your own people answer requests and manage accounts.

Data boundaries and integration

The failure that matters most in a portal is one customer seeing another customer's orders, prices or documents. Preventing it is a design decision, not a test you run at the end.

• Scope on the server, every time. The account comes from the signed-in session, never from a value in the URL or the request body that a user could change. Build the account filter into the data access layer so a new screen can't forget it.
• Test with two accounts. Before launch, sign in as one test customer and try to reach another's orders and documents by changing identifiers in links and API calls. Repeat it as part of every release.
• Read from copies, not the live system. A portal can multiply query load on your core systems, and outside users arrive at unpredictable times. Sync the data the portal shows to its own store, or read through views or an API layer, and show when the data was last updated.
• Queue writes for review. Returns, claims and requests land in a queue your staff approve before anything changes in the system of record, at least until the rules are proven.
• Keep internal data internal. Internal notes, cost prices and margins shouldn't be in the portal's data store at all, so no bug can expose them.
• Log access. Record who viewed and downloaded what, per account. It answers customer questions and security reviews alike.

If the data comes from a business system whose API is limited, our guide to integrating two business systems when one vendor's API is poor covers polling, webhooks, files and reconciliation. Spec sheets, manuals and CAD files that need no sign-in belong on your public website rather than behind the portal's sign-in.

Running a portal after launch

A portal adds a new group of users with expectations your internal apps never had to meet. Decide these before launch, whichever route you choose:

• Who answers portal users. Sign-in problems, missing documents and "this order is wrong" questions need a named team and a place to go, usually the same customer service or dealer support team that answers the phone today.
• Who owns the content. Price lists, documents and announcements each need an owner in the business and a review date, or the portal goes stale and people go back to calling.
• Availability and maintenance windows. Outside users may work different hours and time zones. Agree when maintenance happens and how users are told.
• Monitoring. Alert on errors, failed syncs and unusual sign-in patterns, such as many failed attempts on one account. Our guide to what a proper software handover should include covers monitoring, runbooks and support options.
• Accessibility and phones. Dealers and field technicians often use the portal from a phone. Design for small screens from the start, and to a recognized accessibility standard such as the W3C's WCAG 2.2 at level AA, which customers may ask about.
• Adoption. Track how many accounts sign in each month and how the call and email counts you measured at the start have changed. That is the portal's scorecard.

Before you choose a route

Our experience includes full-stack web applications with OAuth and OIDC sign-in, and subscriber sign-in for audio and video streaming apps with 200,000+ active users (experience, not client work). Our own product, Round Table, uses Amazon Cognito for sign-in. See web application development for how we'd approach your portal, and what drives the cost of custom software for comparing quotes on a custom build.

Sources

• Amazon Cognito user pools and federation with SAML and OIDC identity providers (AWS)
• Web Content Accessibility Guidelines (WCAG) 2.2 (W3C)