01
Number and type of user roles
A portal with one customer role is simpler than one with customers, branch managers, sales staff, warehouse users and administrators. Each role adds screens, permissions and testing.
Business Operations & Custom Software
What Affects the Cost of a Customer Portal?
There is no honest universal price for a customer portal, because the cost follows the scope: what customers can see and do, which systems connect, and who maintains it afterward. This guide explains the decisions that move the scope—so you can plan before anyone quotes.
Checks and notes stay only in this open page. They are not saved and reset when you refresh or leave. Nothing you enter is submitted or stored by this worksheet. Print to keep a copy. Use general planning notes—not passwords, customer records, confidential pricing or other sensitive information.
Scope first. Price second.
An accurate proposal follows a defined scope and a review of your existing systems—not the other way around. Any quote given before those conversations is a guess. Use this guide to walk into that conversation prepared.
The decisions that shape the scope.
Each of these adds or reduces development effort and ongoing cost. You do not need final answers—honest ones are enough to start.
02
Customer account approval and permissions
Deciding who may open an account, who approves it, and what each person may see or change shapes the sign-up flow, the admin tools and the review work behind them.
03
Information customers need to view
A list of documents is straightforward. Live order status, account-specific pricing or inventory levels require dependable connections to the systems that own that information.
04
Actions customers can perform
Viewing information is simpler than acting on it. Requests, orders, payments, approvals and file uploads each add workflow rules, confirmations and error handling.
05
Existing data quality and migration
Clean, consistent customer and product data moves easily. Years of duplicate accounts, inconsistent SKUs or missing fields must be cleaned and mapped before a portal can rely on them.
06
Connections to CRM, inventory, accounting or other systems
Each connection depends on what the other system allows: available APIs or exports, account permissions, provider fees and how often information may update.
07
Pricing rules, ordering, payments and approvals
Account-specific price lists, quote-only products, spending limits, payment methods and multi-step approvals are real business rules that must be defined before they can be built.
08
Documents, uploads, notifications and reporting
Statements, safety sheets, delivery photos, email or text notifications and management reports each add storage, delivery and formatting work.
09
Mobile requirements
A portal that works in a phone browser is a different scope from a dedicated app, offline use, or scanning with specific warehouse devices.
10
Testing, training, hosting, maintenance and support
Launch is not the end. Testing with real scenarios, training the team, hosting, updates, backups and support are ongoing responsibilities that belong in the plan.
11
Third-party subscription, transaction and usage charges
Payment processing, text messaging, mapping, email delivery and connected-system fees are charged by their providers and continue after launch. They are separate from the build itself.
Three illustrative scopes.
These are planning examples, not fixed packages or prices. They show how scope grows—and what makes each step more involved.
Scope 01
Planning example: a simple portal for documents and requests
Customers sign in to see their documents and submit a request or question. One or two roles, no live system connections, and staff handle each request manually. This is the most contained scope: the main work is a clean sign-in, a document area and a request form that reaches the right person.
Scope 02
Planning example: a connected portal for account information and workflow updates
Customers see account information, order or job status drawn from existing systems, and receive updates as work moves. This adds connections to one or more business systems, rules about what each customer may see, and dependable update timing. The connections—and the quality of the data behind them—are what make this scope more involved.
Scope 03
Planning example: a complex portal with multiple roles, integrations and approval rules
Several customer and staff roles, account-specific pricing, ordering with spending limits, multi-step approvals, payments and connections to inventory and accounting. Every rule must be defined, built and tested, and every connected system adds its own constraints. This is a substantial operational project, not a website add-on.
Many businesses launch at the first or second scope and grow later. A smaller first version that people actually use beats a large one that launches late.
The First Version vs. Later worksheet.
Print this and fill it in with your team. Deciding what can wait is as valuable as deciding what launches first.
Questions to ask any developer.
Bring these to every proposal conversation—including ours. Straight answers here matter more than a polished pitch.
- What exactly is included in the proposal—and what is not?
- Which assumptions does the quote depend on, and what happens if they change?
- Which ongoing charges are separate: hosting, third-party services, support?
- How are changes requested, priced and scheduled after we agree on a scope?
- How can we export our data, and in what format?
- What happens after launch: who maintains it, and how are problems reported?