An Australian service business wants to reduce routine calls and emails. Customers keep asking whether an invoice was received, a request has progressed or a document has been verified.
The requirement sounds simple:
Can we send the customer a link so they can see the update without creating an account?
Before the page even opens, what could someone already learn from the URL itself—an invoice number, case type, customer sequence or internal process?
One development team says yes. It proposes a tracking page, places a random value in the URL and estimates the work.
The Right Questions to Ask
Another team pauses before estimating. It asks:
- Who will receive the link?
- What exact question does the customer need answered?
- Which system holds the source information?
- What would happen if the link were forwarded?
- Which information must never leave the internal workflow?
- Who will own the feature after launch?
Both teams may be able to produce a page that looks correct in a demonstration. Only one has shown that it understands the business problem behind the page.
That difference matters in customer portal development. The visible screen is usually the simplest part. The harder work sits underneath it: workflow, integration, privacy, access decisions, exception handling and long-term ownership. A tracking page is a feature; a customer self-service capability gives customers useful access without creating more work or exposing more information than intended.
The short answer: Give every prospective development partner the same real customer journey. Assess whether they can understand the workflow, justify the access model, separate external access from internal records, test misuse and own the feature after launch. Together, these five capabilities provide a more useful way to assess delivery judgement than relying on a feature list or polished proposal alone.
This article gives Australian SMEs an access-model table, a URL risk screen, a partner scorecard and a pre-launch check to run against one real journey. For a broader assessment of delivery partners, see Offshore Software Development for Australian Businesses.
Five Factors That Separate the Partners Who Understand Your Business
1. Do They Understand the Real Customer Workflow?
A portal should not be designed around the database record or the internal team that requested it. It should be designed around the external user's question and the operational process that produces the answer.
For an invoice-status journey, the customer may only need to know that the invoice was received and when to expect the next update. They may not need to see an internal invoice number, finance queue, approver, account note or exception code.
The same test applies to an NDIS self-service journey: a participant may need a clear status and next step, not internal case notes, staff assignments or workflow codes.
The provider should also identify who sends the link, what triggers it, how incorrect information is corrected and where support staff look when the customer calls.
What to ask: Ask the provider to draw the journey from the triggering event to the customer's next step, including which system owns each piece of information and who supports it after launch. A strong team explains the workflow in business language, identifies missing decisions and challenges unnecessary exposure or complexity.
What Shinetech's published approach shows: Shinetech's How We Partner model says developers receive business context before a project begins, while its custom software approach starts with business goals before code. In a portal evaluation, the evidence to request is a journey mapped in your own operational language—not a generic discovery presentation.
2. Can They Choose the Right Access Model?
"Public link or login?" is not a visual preference. It is a business-risk decision.
| Customer journey | Typical exposure | Access model to consider | Decision question |
|---|---|---|---|
| Check a low-sensitivity delivery or request status | A limited status and next step | An opaque, expiring link may be appropriate | Would disclosure cause meaningful harm? |
| View personal details or customer-specific history | Personal or commercially sensitive information | Login, identity check or another verification step | How do we know the viewer is the intended person? |
| Open an invoice, claim, care record or full document | Detailed financial, health or case information | Authenticated portal with record-level authorisation | Is possession of an emailed link enough evidence of identity? |
| Upload a document, approve a request, change details or make a payment | An action changes data, money or an obligation | Authenticated session; stronger verification for higher-risk actions | What is the consequence of the wrong person completing the action? |
The goal is not to force maximum friction into every journey. It is to choose friction deliberately according to the user, the information and the consequence of misuse.
| Ask the provider | Weak answer | Strong answer |
|---|---|---|
| Can customers check status without logging in? | "Yes. We'll generate a random URL." | "Possibly. First we would define the information returned, the risk if the link is forwarded, expiry and revocation rules, and whether the journey requires login or another verification step." |
Where personal information is involved, Australian Privacy Principle 11 requires organisations to take reasonable steps to protect it from misuse, interference, loss, unauthorised access, modification or disclosure. Public-link design may form one part of those technical and organisational steps; an opaque URL alone does not establish compliance.
This article is a practical vendor-evaluation guide, not legal, privacy or cybersecurity advice. The appropriate model depends on the data, the user, the consequences of misuse and the obligations applying to the organisation.
What to ask: Ask the proposed team to justify the access model against your information, users and consequences, and record the decision before implementation. Organisational certifications do not decide whether a particular journey should be public or authenticated.
3. Can They Separate External Access from Internal Records?
Read the proposed URL before looking at the page. A route such as /track/invoice/INV-104392 reveals business meaning and an internal numbering format; /track/status/<opaque-token> hides that meaning but is only one layer of protection.
A Quick URL Risk Rating
This is an initial screening framework, not an industry-standard security rating. Actual risk depends on the data exposed, the surrounding controls and the consequences of misuse.
| Risky or safer signal | Initial risk signal | Why it matters |
|---|---|---|
/invoice/INV-104392 | High | Exposes business meaning and a format that may be tested by changing nearby values. |
/track/123456789 | Medium | A sequence-like value may be easy to predict, enumerate or compare over time. |
/track/<strong-opaque-token> | Lower—not automatically safe | Hides business meaning and reduces predictability, but still requires server-side validation, a limited response, expiry, revocation and monitoring. |
The public token should map to the internal record through a controlled server-side layer. In an anonymous journey, the server validates the bearer token and enforces its exact data boundary; it is not proving that the viewer is a particular authenticated person.
A random-looking identifier is not a replacement for access control. OWASP guidance on insecure direct object references recommends server-side checks for each protected object and describes complex identifiers as defence in depth rather than the primary control. The Australian Signals Directorate's guidance on web application access-control abuse likewise focuses on correct authentication and authorisation.
What to ask: Ask how the server validates every request, including token scope, expiry, revocation and response-field restrictions. A strong answer names the public fields, internal fields, token rules and circumstances that require authentication. The response should contain only the minimum useful information, while altered and repeated requests fail safely.
If the page contains sensitive information or allows a consequential action, the answer may still be "require authentication". A well-designed token cannot make every workflow suitable for anonymous access.
Also ask how the team addresses leakage through errors, caching, indexing, referrers, analytics, logs and support tools—not simply whether the portal will be "secure".
4. Do They Test Misuse Before Launch?
Most portal demonstrations show the intended path: the right customer opens the right link and sees the right result. That proves the feature works. It does not prove the boundary works.
Before approving the design, ask to see what happens when:
- one character in the token is changed;
- the link is opened repeatedly or by an automated script;
- the link is forwarded, expired or revoked; and
- the underlying record or API response changes.
What to ask: Put at least one invalid, expired, forwarded and repeated-link scenario in the acceptance criteria and ask the provider to demonstrate them. Failure messages should not confirm whether a customer, invoice, claim or document exists; logs should support investigation without placing unnecessary sensitive information in analytics or support systems.
5. Will They Own the Feature After Launch?
Portal fields change. Integrations expand. Support teams request more detail. An endpoint designed for one journey gets reused for another.
The partner should document the access model, public fields, expiry rules, logging, monitoring and change controls. It should be clear who reviews unusual activity, who can revoke access and how future changes are checked against the original boundary.
What to ask: Ask who owns the workflow after go-live, what is included in handover and how a future field or integration change will be reviewed. Strong evidence includes documented business rules, access decisions, monitoring and operational ownership.
What Shinetech's published approach shows: The Australian custom software service includes maintenance, performance monitoring and feature-roadmap support after launch. Ask how those services would apply to this portal, who would retain context and what is included in handover.
How Delivery Models Compare
A useful comparison is whether an engagement starts from the requested feature or the customer and operational workflow behind it. Apply the same test to every provider—including Shinetech—and ask the proposed team to demonstrate its approach against your journey.
| Decision area | Feature-first delivery | Workflow-first delivery |
|---|---|---|
| Starting point | The requested page and feature list | The customer outcome, users, process and source systems |
| Access decision | The lowest-friction option is selected by default | Friction is justified against the information, action and consequence |
| Project evidence | A general statement that the solution will be secure | Named public fields, internal fields, access rules and misuse acceptance criteria |
| After launch | Responsibility ends at go-live | Monitoring, ownership, handover and future changes are planned before launch |
| Continuity | Knowledge may remain with individual developers | Business rules and access decisions remain documented and reviewable |
Shinetech's published approach aligns with the workflow-first model: How We Partner starts with business context and goals, while its custom software service includes customer portals, post-launch maintenance, performance monitoring and feature-roadmap support. The website also reports 900+ Australian clients and 420+ partnerships lasting two years or more. These are useful indicators, but the proposed team should still demonstrate the model against your real journey.
The potential value is not simply the hours spent building the first link. It is also the opportunity to reduce rework, customer confusion and avoidable risk across the portal journeys that follow.
A portal becomes valuable when it reduces work for the customer and the business without making the internal system easier to read from the outside.
Customer Portal Partner Evaluation Scorecard
Rate each factor from 1 to 5, where 1 is vague or unproven and 5 is specific, demonstrated and documented. This is a practical internal comparison tool, not an industry benchmark or security certification.
| Factor | Score (1–5) |
|---|---|
| Understands the external user and operational workflow | |
| Justifies the access model in business terms | |
| Separates external access from internal identifiers and fields | |
| Demonstrates misuse and failure scenarios | |
| Defines ownership, monitoring and future change controls | |
| Total / 25 |
- 21–25: Strong evidence worth validating against references, contract terms and the proposed team.
- 15–20: Material gaps to clarify before the full build is estimated.
- Under 15: Pause and investigate whether your business is supplying workflow analysis, access decisions or delivery governance that the partner should bring.
Use the lowest-scoring factor to identify where assumptions or delivery risk require the most attention before expanding the portal scope.
Pre-Launch Sign-Off Check
Use this four-part check in a kickoff or pre-launch review. Ask the delivery team to demonstrate the answer against the working journey.
| Sign-off question | Strong evidence | Stop-and-review signal |
|---|---|---|
| What appears in the public URL? | No readable invoice, customer, case or sequence value | An internal identifier or business process is visible |
| What can the external page return? | Only the minimum customer-safe answer and next step | Internal notes, account identifiers or workflow states are returned |
| How does the link fail? | Altered, expired and revoked links fail consistently without confirming a record exists | Error messages reveal which invoice, customer or document was tested |
| Who owns the boundary after handover? | Public fields, token rules, monitoring and change controls are documented with an owner | The behaviour is known only to the original developer |
If the team cannot demonstrate all four answers, the feature is not ready for sign-off even if the happy path works.
Three Terms Worth Clarifying
| Term | Plain-language meaning |
|---|---|
| Bearer link | A link that may grant access to whoever possesses it. Forwarding the link may also forward the access. |
| Opaque token or public lookup key | A sufficiently strong value with no readable business meaning, used by the server to locate and constrain a public request. |
| Enumeration | Changing predictable values—such as INV-104392 to INV-104393—to test whether other records exist. |
Frequently Asked Questions
What is customer portal development?
Customer portal development is the design and implementation of a secure external experience through which customers can view information, complete self-service tasks and interact with connected business systems. A portal may support status tracking, invoices, documents, requests, payments, bookings or account management. The work includes the user journey, integration, access rules, exceptions, monitoring and support—not only the interface.
What should an Australian SME look for in a customer portal development partner?
Look for a team that can understand the operational workflow, identify the minimum useful customer outcome, justify when public access or login is appropriate, protect internal identifiers and data, demonstrate failure scenarios and take responsibility after launch. Ask for specific answers against one of your real journeys rather than relying on a generic security or capability statement.
Are public tracking links safe for Australian businesses?
A public link acts like a bearer credential: anyone who receives it may be able to use it unless additional verification is required. It may be appropriate for limited, low-risk information when the token is strong, scoped, expiring and revocable; the server limits the response; and monitoring and leakage risks are addressed. Sensitive information and consequential actions may require authentication.
Is a random token in the URL enough to protect a customer record?
No. An opaque token reduces predictability and hides internal identifiers, but it does not replace server-side validation, scope checks, expiry, revocation, response minimisation and misuse monitoring—or authentication and authorisation where the journey requires them.
When should a customer portal require login?
Consider login or stronger verification when the portal exposes personal, health, financial or commercially sensitive information; provides a customer-specific history or full document; or allows someone to upload, approve, pay or change data. The decision should be based on the information, action and consequence of unauthorised access.
How does Shinetech approach customer portal development in Australia?
Shinetech's Australian website lists customer portals, self-service experiences and partner platforms as custom software capabilities. Its published approach starts with the client's business processes, users and objectives before development, with Forward Deployed Engineering available for discovery and validation before full-scale investment. Shinetech also provides maintenance, performance monitoring and feature-roadmap support after launch.
Choosing Well Matters More Than Building Fast
A public link can look like a small feature to estimate and build. What determines whether the portal succeeds is what happens around that link: the workflow it represents, the systems it exposes, the decisions it encodes and the team that owns it after launch.
The same is true for the next portal journey—document verification, invoice access, participant updates, customer requests or payments. If the boundary is explicit and reusable, the portal can expand without reopening the same hidden assumptions each time.
Is your development partner estimating a page, or helping you design a customer capability?
Shinetech's Australian website lists customer portals, self-service and partner platforms as custom software capabilities, with maintenance, performance monitoring and feature-roadmap support after launch. Its How We Partner and Forward Deployed Engineering approaches start with business context and solution validation. The site reports 900+ Australian clients, 420+ partnerships lasting two years or more, and organisational trust controls including ISO 27001 and Cyber Essentials Plus. These indicators do not make any specific portal automatically secure or compliant; the proposed team should still demonstrate the five factors in this article against your journey.
Next steps for your team:
- Use the URL risk table to audit one current or proposed external link.
- Bring the pre-launch sign-off check to your next project or vendor meeting.
- Ask the delivery team to demonstrate one real journey through normal, invalid, expired and forwarded-link scenarios.
If you are planning a customer portal or self-service workflow, bring us one real journey. We can help you clarify the business outcome, access model and delivery approach before you commit to the full build.
Related reading: How to evaluate offshore software development partners · How Shinetech partners with software teams · Custom software development
Sources
- Office of the Australian Information Commissioner. Australian Privacy Principle 11 — Security of personal information.
- OWASP Cheat Sheet Series. Insecure Direct Object Reference Prevention Cheat Sheet.
- Australian Signals Directorate, Australian Cyber Security Centre. Preventing web application access-control abuse.
- Shinetech Software Australia. Custom Software Development, Forward Deployed Engineering and How We Partner.
About Shinetech Software: shinetechsoftware.com.au | Sydney and Melbourne | 900+ Australian clients | 420+ partnerships lasting two years or more | ISO 27001 & Cyber Essentials Plus.