A customer portal is useful when customers need to complete a recurring task with your business: supply a file, review a proposal, check a project update or answer a request. A login screen alone does not solve any of those jobs.
Before asking for a development quote, describe the exchange that currently creates confusion. What is requested, who responds, what counts as complete and where does the final record belong? That description helps you compare an existing tool with a custom website feature.
Start with one complete customer journey
Choose a frequent task and follow it from beginning to end. For example, your team requests a drawing, the customer uploads it, a coordinator checks it and the customer sees either accepted or changes requested. Identify who handles a missing file or an unclear response.
This is more useful than a wish list containing messaging, dashboards, payments and automation. A first version should finish a real task without staff having to create a second unofficial record in email.
Use the website project preparation guide to assemble your existing process and content before discussing the build.
Compare what you already have with a custom portal
If customers only need to receive a document, controlled sharing may be enough. Microsoft documents external collaboration with customers through SharePoint and OneDrive, with permissions affected by organisation and site settings. Microsoft external sharing guidance.
Check whether your existing CRM or project system already supports the task. Test its customer experience before adding another application.
| Option | Consider it when | Question to resolve |
|---|---|---|
| Email and controlled file sharing | Exchanges are occasional and easy to track | Who keeps the agreed final version? |
| An existing system's customer area | The records and workflow already live there | Can customers complete the task without staff workarounds? |
| A custom portal | Specific roles, records or approval steps remain unsupported | Which requirement justifies development and ongoing support? |
Compare the whole responsibility: customer access, administration, support, data export and maintenance. Branding alone is rarely a complete business case.
Write the visibility rules before drawing screens
List the people who use the portal and the records each should see. Separate customer-visible material from internal drafts. Decide who is allowed to publish an update to a customer.
The following matrix is an illustrative starting point, not a description of an existing Nolixia customer system.
| Action | Customer | Assigned coordinator |
|---|---|---|
| View project status | Own project only | Assigned projects |
| Upload a requested file | Own open requests | Assigned projects |
| Publish an internal draft | No | Explicit permitted action |
| Record a review decision | Named reviewer only | See and process the response |
| Open another customer's files | No | Only when assigned |
OWASP distinguishes signing in from having permission to a particular resource. It recommends minimal access and permission checks on every request. Your buying brief should require proof that customer accounts remain separated. OWASP authorisation guidance.
Tie approval to the version actually reviewed
An approval needs a defined subject. Record the document version, reviewer, decision and time. If someone replaces the document, decide whether the previous approval still applies; do not let the interface silently transfer it to different material.
An illustrative journey might show Requested, Uploaded, Under review and Accepted. A request for changes should explain what needs attention and where the customer can submit a replacement. Use wording appropriate to your process; a workflow confirmation should not automatically be presented as a legal electronic signature.
For uploads, state the required file formats and sensible size limits. Ask the developer to validate uploads and protect stored files, rather than assuming an upload button handles those responsibilities. OWASP file upload guidance.
Ask for these demonstrations before launch
- Invite two test customers and confirm that each sees only their own records.
- Try opening a copied file address using the other test account; access should be refused.
- Replace a reviewed file and check how its version and decision history appear.
- Revoke a test user's access and confirm it stops working.
- Complete the journey on a phone, including an invalid or oversized upload.
- Check that staff can find unanswered requests and correct an accidental update.
- Export a sample completed record and identify who maintains the portal after launch.
Bring a focused brief to Nolixia
Prepare an anonymised example request, the systems holding your records, user roles, required file types and the outcome you want. Include the exceptions that currently force a phone call or an extra email.
Explore Nolixia's website, dashboard and integration services, then send your portal requirements. We can discuss whether configuration, integration or a custom portal is the appropriate next step. The useful starting point is a clear workflow, rather than a commitment to build every possible feature.
