The three-criteria test before building a portal. Most businesses skip this step and build the wrong features first.
A customer portal is a significant engineering investment. Before building one, the question is whether the business model actually justifies it. The answer depends on three factors: transaction frequency, relationship duration, and document complexity. Get these wrong and you’ve built a feature nobody uses.
Before building the portal, I had to answer an honest question: does this business have the kind of customer relationship where a portal adds value? The criteria:
For the Anchor build, all three applied: repeat buyers existed (the average customer returned within 24 months), consignors needed visibility into unit status, and the document exchange was currently a mix of email attachments, DocuSign, and physical paper.
Before writing a line of code, I mapped the portal’s four core use cases and estimated the usage frequency for each:
| Use case | Usage frequency | Value without portal | Portal ROI |
|---|---|---|---|
| Check unit status | Weekly (consignors) | Phone call to office | High |
| View purchase history | Occasional | Manual lookup by staff | Medium |
| Download documents | Per transaction | Email attachment request | High |
| Update contact info | Rare | Phone/email to staff | Low |
High-ROI use cases (status visibility and document access) justified the build. The “update contact info” case alone would never justify a portal — but it’s trivially cheap to include once the infrastructure exists.
The portal is not a full-featured account management system. It doesn’t let customers make payments, negotiate prices, or contact support. Those are separate features with higher complexity and different trust assumptions. The portal does exactly two things well: show the customer what’s theirs and let them get their documents.
Scope discipline is critical. The moment the portal becomes “while we’re in here, let’s also add…” it becomes a product instead of a feature.
The first version included:
owned_units recordsEverything else was deferred.
The “just checking in” call pattern is real and expensive. A consignor who wonders whether their unit has had any inquiries calls the office. The front desk looks it up, tells them, and moves on. That’s a 5-minute interaction that scales with the number of consignors. With 30 active consignments, that’s potentially 30 “checking in” calls per week. A portal that shows real-time status eliminates those calls without requiring any staff involvement.
Portal adoption — 34% of active customers in the first 30 days — was driven almost entirely by consignors checking unit status. Buyers used it for documents. The contact-info update feature saw almost no usage in the first three months.
The portal shipped at the end of Era 3 with exactly the minimum feature set described above. The scope was held to four components: login, my units, my documents, status display. Nothing else.
Six months after shipping, the addition of a “request a showing” button on each unit card was the only scope addition. It was a single form submission that created a new lead record in the CRM. Total additional engineering: 2 hours.
Every lesson stays free — no account, no paywall, no email gate, ever. But if you’d rather have this system standing on your business than wire all 48 lessons yourself, leave your email. We’ll send you a direct line to a build — and you’ll be first to hear when we add new tools to the curriculum.
None of this gates a single lesson. The curriculum was free before you got here and it stays that way.
You came here to understand the system, and now you do. If you’d rather have it standing on your business than spend the next three months wiring it yourself, GAP Concierge is the same architecture from these lessons — a white-label AI agent that knows your catalog and captures your leads — set up for you, from $97/mo.
See GAP Concierge →