Count the calls before you draw a single screen
A portal is a trade. You are asking a customer to create an account, remember how to get back in, and learn a layout, and in exchange you promise them something faster than picking up the phone. If the thing they get back is small, they will not make the trade twice. This is why so many portals show good sign-up numbers in month one and a flat, sad usage line by month four. The design was never wrong. The trade was.
So before anything else, find out what the phone is for. Pick the last four weeks. Have whoever answers the phone tag each call with a reason from a short list they wrote themselves, not one you handed them. Two weeks of tagging, done honestly, is worth more than a quarter of workshops. Most distributors, clinics, contractors and specialty manufacturers we have looked at land on the same shape: five or six reasons account for roughly three quarters of inbound volume, and the tail is genuinely a tail.
The five that keep showing up are: where is my order, what do I owe and can you resend the invoice, send me a copy of a document, I need to change something, and something is wrong. Those are not equally good candidates. Two of them are lookups a portal does beautifully. One is a document retrieval problem. One is a write, which is a different and much larger project. And the last one should always reach a person quickly, because a customer who is angry and gets a form is a customer who is angrier.
You are probably here because
- Two people spend most of the day answering “where is my order” on the phone
- A portal was launched last year and roughly nobody uses it
- Your biggest customer asked for one and you do not know what it should contain
- Customer service keeps emailing PDFs out of a folder nobody can find twice
All four are the same question in different clothes: what is the smallest thing that takes real work off the phone, and does it justify charging your customers a login.
The honest answer is sometimes that you do not need a portal
If seventy percent of your call volume is one question with one answer, you probably need a page, not a portal. A tracking link in the shipping confirmation email, pointed at a page that needs no login and takes an order number, will absorb more calls than a full account system, and you can have it in three weeks. A specialty parts distributor we talked with had five people fielding status calls; the fix that moved the number was not a portal, it was putting the carrier tracking number into the order confirmation email, which had been sitting unused in their order system for years.
Portals earn their keep when a customer has an ongoing relationship with real state in it. Multiple open orders. An account balance. A history of documents they need again later. Several people at their company who each need a different slice. If your customer buys from you twice a year and forgets you in between, they will never remember the password, and every login will end in a reset email.
Identity is the hard part, and it is not the login screen
Authentication is a solved problem you should buy rather than build. The hard problem underneath it is that your business systems model a customer as an account number, and reality is a company with six people in it who should not all see the same things.
Consider a mechanical contractor buying from a supply house. The purchasing manager needs pricing, order placement and invoices. The field superintendent needs to know whether the rooftop units shipped and nothing else. The controller needs statements and nothing else. If everybody who logs in against account 40122 sees everything on account 40122, you have just published your negotiated pricing to a foreman with a phone in a truck, and the first time a customer notices that they will tell you about it in a way you remember.
So the model has three layers, and it is worth drawing on a whiteboard before code: the company, which usually maps to one or more identifiers in your order system; the person, who has an email and a login; and the grant, which says what this person can do on this company. Grants are not roles. Roles are a shortcut that stops working the second a customer with nine clinic locations asks for someone who can see all sites but only pay for two.
Two more cases arrive later and cost more if you did not plan for them. Parent and child accounts: a restaurant group with eleven locations wants a rolled-up view, and each general manager wants only their store. And delegated administration: your largest customers will want to add and remove their own users, because otherwise every staffing change becomes a support ticket for you. Give them that screen. It is the cheapest support you will ever ship.
| Capability | Who typically needs it | What it costs you to get wrong |
|---|---|---|
| See order status | Nearly everyone at the customer | Little. Make this the widest grant |
| See prices and quotes | Purchasing, owners | Published pricing, an awkward call |
| See invoices and balance | Accounting, owners | Salary-adjacent embarrassment, disputes |
| Place or change an order | A named few | Real money and a real argument |
| Manage their own users | One admin per company | Every staff change becomes your ticket |
The portal shows your customers your data quality
This is the part nobody budgets for and everybody discovers in week six. Internally, your order system's status field has fourteen values. Three of them mean roughly the same thing to a customer. One says WHSE-HOLD-B and only means something to the second-shift lead. Two are left over from a system you replaced in 2018 and still appear on old records.
You cannot put that field on a customer screen. What you can do is write a translation table: fourteen internal values map to five customer-facing states, and each customer-facing state has one sentence of plain explanation and, ideally, a date. Doing that mapping is a two-hour meeting with the person who actually knows, and it is the single highest-value hour in the project. It also tends to surface the fact that two of the fourteen values are used inconsistently by different branches, which is a real operational finding you got for free.
Dates are the second exposure. If your promise date is a field somebody updates by hand when they remember, the portal will make that visible at scale, and customers will start holding you to a number your own team never trusted. Decide before launch whether you show it, show a range, or show nothing and say “we will confirm.” Showing an unreliable date is worse than showing no date, because you have converted an internal guess into a promise.
Never show a field you would not read out loud on the phone
A useful filter for any candidate field: would a good customer service rep say this sentence to a customer who called? If the answer is “no, I would translate it first,” then the portal has to do the same translation. Every raw internal code that reaches a customer screen generates the exact call the portal was built to prevent, plus a second call asking what the code means.
Read-only first, and mean it
The difference in cost and risk between a portal that shows things and a portal that changes things is not a factor of two. It is closer to a factor of four, and almost all of the difference is in the parts nobody demos.
A read screen that is briefly wrong is annoying. A write that is briefly wrong creates an order you have to unwind, a payment you have to refund, or a cancellation that reached the warehouse after the truck left. Writes need validation against live inventory and credit, an idempotency guarantee so a double-click does not create two orders, a state machine for what can still be changed and by whom, and a path for the exception where the answer is “call us.” A first version that does reads well and does one narrow, well-guarded write is a much better product than one that does five writes shakily.
When you do add a write, pick the one that removes the most phone time, not the one that sounds most modern. In a supply business that is often reorder from history, because most orders are a repeat of a previous order with two lines changed. In a clinic group it is almost always rescheduling. In field services it is uploading a photo against a job.
Where the effort goes on a first portal — our typical split
Percent of build effort on a read-mostly first version. Judgment from projects of this shape, not a measurement. The point is that screens are the small part.
Documents are usually the sleeper feature
Ask a manufacturer's customers what they want and they will say order status. Watch what they actually download and it is certificates. Mill certs, certificates of analysis, test reports, safety data sheets, signed delivery tickets, lien waivers. These are documents a customer needs months after the transaction, usually urgently, usually because their own customer or auditor asked, and today they get them by emailing your inside sales rep, who searches a shared drive.
Putting those documents behind a search that takes a lot number, an order number or a date range is not glamorous and it removes a category of interruption that never shows up in a call-reason list because it arrives by email. If you serve regulated buyers, contractors doing closeout packages, or anyone whose own compliance depends on your paperwork, check this before you assume status is the winner.
Freshness, and the two-minute lie
How current the data is decides how much trust the portal earns. A nightly extract is perfectly fine for invoices and statements, which do not change hourly. It is fatal for order status, because the customer's whole reason for looking is that something changed today.
You have three practical patterns. Read live from the system of record on each page view, which is simplest and correct but can be slow and puts portal traffic on a database your operation depends on. Cache with a short lifetime and show the timestamp. Or maintain a replica updated by change events. Most mid-size businesses land on the second: a few minutes of staleness, clearly labeled. The label matters more than the number. “As of 9:14 this morning” is honest and nobody complains. Silent staleness produces the call you were trying to avoid, with a customer who now trusts the screen less than the phone.
Send us your call log and we will tell you what to build first.
Two weeks of tagged call reasons, a rough count of active customers, and the name of your order system. Email it to contact@precisionfederal.com and you get back a short written note on what a portal would and would not absorb, and where the integration is likely to be hard. One business day, no charge.
contact@precisionfederal.comOne search box, and a first screen that answers the question
The most useful thing on a customer portal is a single search field that accepts any identifier the customer might have in their hand: your order number, their purchase order number, an invoice number, a part number, a tracking number, a job name. Customers do not know which of those is the “right” one and should not have to. Detect and route.
The landing page should answer the top call reason without a click. If status is the winner, the landing page is a list of open orders with their state and date, newest first, not a dashboard of tiles. Tiles are what a portal has instead of an answer. Every extra click between the login and the answer costs you a measurable share of the people who came looking for it.
Assume a phone. Not because mobile is a trend, but because the person who most wants order status is standing on a job site, in a stockroom, or between patients. If the table does not read on a five-inch screen, the feature does not exist for the person who needs it most.
Email is the portal for most of your customers
Accept this early and design with it. A proactive email when the state changes — shipped, delayed, ready for pickup — removes more calls than a portal login ever will, because it reaches people who will never log in. Every one of those emails should contain a deep link that lands on the exact record, and that link should work without a password prompt if it is scoped narrowly and expires.
Password friction is the quiet killer. If a customer logs in every six weeks, they will not remember their password, they will hit reset, the reset email will land in a spam folder at a company with strict filtering, and they will call you. Email link sign-in removes most of that. Single sign-on is worth building only if your largest customers ask for it, and the ones who will ask are the ones with an internal identity team.
Roll out to the loudest twenty, not to everyone
The instinct is to announce it to the whole customer list. Do not. Take the twenty customers who call the most, tell them by name that you built this partly because of them, sit with two of them while they use it, and fix what you see. This does three things: it produces real usage data instead of curiosity clicks, it finds the identity and permission mistakes while they are cheap, and it converts your heaviest support burden into your first advocates.
Watch for one specific signal during that period: your own staff. If a customer service rep keeps doing something by hand for a customer who has portal access, that is not a training problem. It means the portal path is slower or less trustworthy than what she already knows how to do, and she is right. Go find out why.
What to measure, and the one number people skip
Sign-ups and sessions are vanity. Track four things instead. Call volume by reason, compared against the same reason before launch, which is the only number that ties to money. Portal sessions per active customer per month. Task completion, meaning the person came for a thing and left having got it. And the number nearly everyone skips: started in the portal, finished on the phone.
That last one is the honest measure of whether the portal works, and you get it by having reps tag calls where the customer says they already looked. A rising number there is not a sign of adoption. It is a list of the exact places the portal falls short, delivered free, in the customer's own words.
What this costs and how long it takes
For a read-mostly first version over an existing order system, with company-and-person identity, a real status translation, document retrieval, notifications and a mobile layout, plan on roughly eight to sixteen weeks and a build cost in the low-to-mid six figures depending almost entirely on how hard your order system is to read from. A modern system with a decent interface sits at the low end. An older installation where the practical integration path is a nightly file or a reporting replica sits at the high end, and the difference is mostly integration work, not screens.
Then budget for the part that gets forgotten: someone owns it after launch. Not a project team — a person, with a few hours a week, who reads the support tags, keeps the status translation current when operations adds a code, and decides what ships next quarter. Portals do not decay because the software rots. They decay because the business changed and nobody updated the mapping, and one day the most common status on the screen is one the portal calls “processing” and the customer knows means something else.
The mistakes we get called in to fix
- A dashboard of tiles where the top call reason needed to be the first thing on the page
- Account-level access only, so a field employee can see negotiated pricing
- Raw internal status codes shown to customers, generating a new category of call
- Nightly data behind a live question, with no timestamp saying so
- Order entry in version one, half-guarded, before reads were trusted
- Launched to the entire list at once, so the first impression was also the buggiest
- No owner after go-live, so the status mapping is two operations changes out of date
- Password-only sign-in for customers who visit every seven weeks
Before you approve the build
- You have two weeks of tagged call reasons, counted, not remembered
- The top reason has a named screen and appears without a click
- Company, person and grant are modeled separately on paper
- Every customer-facing status maps from a real internal value
- Freshness is decided per data type, and shown on screen
- Version one is read-mostly, with at most one guarded write
- Notification emails deep-link to the record
- Twenty named pilot customers are chosen and warned
- Call reasons will be re-counted ninety days after launch
- One person owns it after go-live, with hours in their week
Bottom line
A customer portal is not a website. It is an offer to trade a login for time saved, and the whole design problem is making that trade obviously good on the first visit. Count the calls, model identity properly, translate your internal data into language a customer can act on, be honest about how fresh the numbers are, and ship something small to the people who complain the most. The portals that get used are the ones where the answer is on the screen before the customer has finished reading the page.
Frequently asked questions
Tag two weeks of inbound calls by reason and count them. If a small number of lookup questions dominate and your customers have ongoing state with you — open orders, balances, documents they need later — a portal will pay. If one question dominates and customers buy from you rarely, a no-login lookup page and a better confirmation email will absorb more calls for a fraction of the cost.
Not in version one, in most cases. Writes need live validation, credit checks, protection against duplicate submission, and a clear rule for what can still be changed and by whom. Get reads trusted first, then add the single write that removes the most phone time — usually reordering from history, rescheduling, or uploading something against a job.
It depends on the field. Invoices and statements are fine on a nightly refresh. Order status is not, because the reason someone is looking is that something changed today. A few minutes of staleness is usually acceptable if the screen says so plainly. Unlabeled stale data is worse than no data, because it teaches customers that the phone is more reliable than the portal.
Usually one of three reasons: the answer people came for takes more than one click to reach, the data on the screen disagrees with what they hear on the phone, or signing back in is harder than calling. All three are measurable. The clearest signal is customers who tell your reps “I already looked” — tag those calls and you get a ranked defect list in the customer's own words.
For a read-mostly portal over an existing order system, plan on roughly eight to sixteen weeks and a build cost in the low-to-mid six figures. The spread is driven almost entirely by how hard your order and billing systems are to read from, not by the number of screens. Budget separately for an internal owner afterward, because the status mapping needs maintenance as operations changes.