A customer portal serves people who buy products or services from you and need to see orders, invoices and support. A client portal serves people you do ongoing, project-based work for and need to see deliverables, approvals and time. A partner portal serves businesses that resell, refer or deliver for you and need pricing, leads and enablement. The three look similar on a slide and differ completely in the data model.
Search for any of the three terms and the results blur together, because many software vendors use the words interchangeably. For a team about to commission a build, that blur is expensive. The wrong label leads to the wrong account structure, and account structure is the one part of a portal that is painful to change after launch. This guide separates the three by the relationship behind them, shows what each needs underneath, and ends with a decision table and a sequence for teams that need more than one. It takes a different angle from our customer portal planning checklist, which sorts portals by the jobs they do (self-service, ordering, case, support); here the question is who the user is to you. If you already know you need a portal built, see our customer portal development services.
The one question that separates them
Ask: who owns the relationship, and who owns the data on the screen?
- In a customer portal, the data is about the customer (their orders, balance, tickets) and lives in your billing, ERP or CRM system. The customer reads it and makes small changes: pay, reorder, update an address.
- In a client portal, the data is shared work (a project, a document, a deliverable). Both sides write to it. The client comments, approves, uploads and signs off, and your team replies.
- In a partner portal, the data includes your own commercial information that you choose to expose to another business: price lists, margin tiers, stock, leads, marketing assets. The partner uses it to sell or deliver on your behalf, so what they see is a business decision, not just a permission.
That single distinction drives everything else in the table below.
| Customer portal | Client portal | Partner portal |
|---|
| Who the user is to you | Buys from you | Commissions ongoing work from you | Sells, refers or delivers for you |
| Typical account unit | A person or a company account | A company with named contacts | A partner company with staff and sub-tiers |
| Main jobs | See orders and invoices, pay, track, raise tickets, download documents | See project status, review and approve deliverables, share files, view time and invoices, message the team | See price lists and stock, register or track leads, place orders, access training and marketing assets, view commissions |
| Who writes the data | Mostly your systems; the customer edits a few fields | Both sides, with approvals and comments | Both sides, with deal and order records |
| Source systems | Billing, ERP, CRM, help desk | Project tool, document store, time and billing | CRM, ERP, price management, learning content |
| What goes wrong most often | Customers cannot find the one answer they came for | Approvals and comments scatter back to email | Tier pricing shown to the wrong partner |
| First measure of success | Fewer "where is my order" and "send my invoice" contacts | Faster approvals; fewer status emails | More partner-sourced orders, fewer pricing disputes |
Customer portal: self-service for the people who buy
A customer portal is the default in most conversations, and the right first build for most businesses that sell repeatedly to the same people. The pattern is: a customer signs in, sees their own records, and does the routine thing without phoning you.
Account model. The decision that matters is whether an account is a person or an organisation with several people. Consumers and very small businesses are fine with person-level accounts. Trade customers are not: a purchasing manager, an accountant and a warehouse contact at the same company need different views of the same account, and the company, not the individual, owns the order history. Build the organisation as the parent and users as members with roles (owner, buyer, accounts, read-only). Retrofitting this later means migrating every record.
What it shows. Orders and their status, invoices and statements, payments, delivery tracking, warranty and returns, documents, and support tickets. These come from your ERP, billing and help desk, so the integration quality sets the portal quality. A customer portal that shows yesterday's balance is worse than none, so show a "last updated" time wherever data is not live. Our system integration approaches guide compares the ways to connect them.
What it changes. Edits are small and controlled: contact details, delivery addresses, a reorder, a payment. Changes with consequences (credit limit, price, tax status) stay with your staff.
Client portal: a shared workspace for ongoing work
A client portal is used by agencies, consultancies, accountants, law and architecture firms, and any business whose product is delivered as work over time. Its centre is not a record but a deliverable: a draft, a report, a drawing, a set of accounts waiting to be signed.
Account model. One client company with several named contacts, each with a role in the engagement: the person who approves, the people who comment, a finance contact who only sees invoices. Contacts also change during a long engagement, so the client's administrator should be able to add and remove colleagues without calling you.
What it needs that a customer portal does not.
- Versioned documents with approval states. Draft, in review, changes requested, approved. A client approval is a record you may rely on later, so store who approved, which version and when.
- Threaded comments tied to the item, not a general inbox, so feedback stays attached to the thing it concerns.
- Requests for information that the client can answer and upload against, with reminders when something is overdue.
- Visibility rules per item. Internal working notes live in the same project and must never appear to the client. This is the most common leak in homemade portals: a single "internal" flag that someone forgets to set.
- Time and invoice transparency, if you bill on time and materials.
What it changes. Everything the client does is a contribution to the work, so the audit trail matters more than in a customer portal: who uploaded, who approved, who deleted.
Partner portal: controlled access for businesses that sell or deliver for you
A partner portal serves resellers, distributors, referral partners, franchisees, agents and subcontractors. The relationship is commercial, so the portal exposes commercial information.
Account model. A partner company, with staff, and often a tier or status (referral, reseller, preferred) that decides what the partner can see and at what price. Partner companies may have sub-partners, regions or territories. The tier is data, not code: when you promote a partner, their prices and content should change without a release.
What it needs.
- Tier-aware pricing and catalogue. Each partner sees only the price list that applies to them. Test this with two partners side by side, because showing partner A the prices of partner B is the failure that costs relationships.
- Lead and deal registration. The partner records an opportunity; your team accepts, rejects or reassigns it; both sides see the state. Define the conflict rule (who owns a lead that two partners register) before building, not after the first dispute.
- Orders and stock, if partners buy from you, with the same organisation-level accounts as a customer portal.
- Enablement content. Training, product sheets, brand assets, certification status. This is often the first thing partners use and the cheapest to build.
- Commissions or rebates statements, if you pay them, with a clear calculation record.
- Onboarding. Applying to become a partner, accepting terms, and being activated by your team, ideally with a short checklist of what is still missing.
What it changes. Partners create leads, orders and sometimes quotes, so approval and review steps are heavier than in a customer portal.
Where they overlap, and how to avoid building three portals
A distributor might have customers (retailers who order), partners (sales agents who place orders on behalf of retailers) and, rarely, clients (a bespoke project). That does not mean three applications. The sensible architecture is one portal application with:
- One identity layer. Users sign in once; a user can belong to one or more organisations with a different role in each.
- An organisation type (customer, client, partner) that decides which modules appear.
- Role- and tier-based permissions applied on the server, not just by hiding screens.
- Shared modules reused across types: documents, messaging, notifications, invoices, support tickets.
If you design the identity and organisation model for this at the start, adding a partner area to a working customer portal is a module, not a rebuild. If you design it as three separate sites, you maintain three login systems and three sets of security fixes.
Decision table: which one first?
| Your situation | Build first | Why |
|---|
| You sell repeatedly and staff answer the same "status, invoice, document" questions daily | Customer portal | The saved contact time is easiest to measure |
| You deliver projects and spend time chasing approvals and files by email | Client portal | Approvals and versions are the pain, not records |
| You sell through resellers, agents or franchisees and share price lists by PDF | Partner portal | Tier pricing and lead tracking are the value |
| You serve trade customers who also have sales agents | Customer portal with an agent role | One organisation model; agents act on behalf of customers |
| You are a service provider with both retainers and projects | Client portal, with an invoices module | The shared workspace is the differentiator |
| You only need to share files with a handful of customers | A secure file-sharing tool for now | A portal needs enough volume to repay the build |
| Your CRM or help desk already includes a portal that covers 80% of the need | Configure that portal | Cheaper and faster; build custom only for the remaining gap |
What to decide before you ask for a quote
- Who are the users, and what are they to you? Write one sentence per user type.
- What is the account unit? Person, company, or company with sub-accounts.
- Which system is the source of truth for each screen? If two systems disagree, the portal will show the disagreement.
- What may the user change? List every editable field and who approves changes.
- What must never be visible? Internal notes, other customers' data, other tiers' prices. Each is a test case.
- How are users created and removed? Invitation, self-registration with approval, or provisioning from your CRM. Include who removes a leaver at the customer's end.
- Which first-release modules prove the value? Pick two or three, not twelve.
Our software requirements brief template helps put these answers into a document a vendor can price.
How the work is delivered
A portal build follows the same five steps as any Timeline Digital project: Understand, Plan, Select Technology, Pilot, and Build & Scale. For a portal, the Understand and Plan steps are where the account model, roles and visibility rules are written down, and the free pilot of 2 to 3 key modules is usually the sign-in, the account structure and the one screen users ask for most. There is no fixed timeframe: the schedule for your project is set from your requirements in the Plan step. The free pilot of 2 to 3 key modules is ready in about 2 days. The full project starts after you approve the pilot, and the scope, milestones and terms are agreed after it. Timeline Digital does not publish prices for custom software, because every project is custom.
If you are weighing a customer portal against the other web applications we build, the web application development page shows how portals, dashboards and booking systems relate, and the employee portal page covers the internal equivalent.
About the author and publisher
Timeline Digital is a custom software development company founded in 2013 and headquartered in Islamabad, Pakistan. This guide was written by Usama Asif to help teams choose between a customer, client or partner portal; it describes general practice and is not a quotation.