Project planning guide

Business website or client portal: what do you need?

A business website explains your offer and collects enquiries. A client portal lets people return to their own requests, records or work. If customers need ongoing access to a process, plan that process before choosing screens or a technology stack.

By Shailpar ·

Choose the right starting point

A business website
Start here when visitors mainly need to understand your services, see your work and contact you. A form can capture the first enquiry without creating a customer account. Define who receives it and how the next conversation happens.
A client portal
Consider a portal when customers need to return to their requests, see status, exchange information or view records specific to them. Accounts, permissions, data ownership and ongoing support become part of the scope.
Both, with a clear boundary
A public website can explain the business while a portal handles customer work. Decide which information is public and which belongs behind access controls. Having both does not mean every visitor should be asked to register.

Do not add a portal only because it sounds more advanced. For a small enquiry flow, a website connected to an existing CRM may cover the need. List the work your existing tools already handle before commissioning a replacement.

Map one complete workflow

Use one example request and follow it from start to finish. The simplified support example below describes responsibilities; it is not a claim that every project needs four separate roles.

  1. 1. Customer

    Submits a request and needs a way to see its progress.

  2. 2. Ticket manager

    Checks the request and assigns a responsible support person.

  3. 3. Support person

    Works on the request, updates its status and communicates with the customer.

  4. 4. Admin

    Manages access and reviews the operation across requests.

For each handoff, write down the trigger, next owner, information needed and visible status. Then ask what happens when nobody accepts the request, required information is missing or the customer needs to reopen it. Those exceptions often reveal requirements that a list of dashboard screens misses.

Keep a lead enquiry separate from a support ticket unless the business explicitly needs them connected. A person asking about your services is not automatically an existing customer with permission to see a portal.

Published example: Innoviez

Shailpar’s published Innoviez project combines a public website and CMS with customer, support-user, ticket-manager and admin portals. The case study describes ticket assignment, status updates, customer messaging, SLA tracking and reporting.

This is an example of a website and operational portal serving different parts of the same business. It demonstrates the published workflow and modules. The case study does not publish resolution-time improvements, ticket volumes or revenue results.

Read the Innoviez Support & SLA portal case study

Prepare a brief before requesting a quote

  • Goal: What should a visitor or customer be able to finish?
  • People: Who uses the workflow, and who owns each handoff?
  • Information: What is collected, who may see it and what should remain private?
  • Existing tools: Which CRM, support system or APIs already hold the information?
  • First release: Which single workflow must work at launch, and which ideas can wait?
  • Ownership: Who supplies content, approves changes and handles support after launch?

Describe the information needed using example field names rather than sending real customer records in the initial brief. Budget and timing can then be discussed against a concrete workflow instead of a vague request for “a dashboard”.

Download the reusable project brief (Markdown)

Define what “working” means

For a website, check that the offer is readable on a phone, the enquiry reaches its intended destination and the visitor receives a clear result. For a portal, follow a test request through assignment, progress and completion. Check that one customer cannot see another customer’s records and that each role can only perform its intended actions.

Also agree how failed notifications, unavailable integrations and support requests will be handled. These checks belong in the written scope. A successful demonstration is useful evidence of a working flow; it is not a guarantee of future enquiries or sales.

Explore business website design, web application and client portal development, or discuss your brief.