How to structure an NDIS provider website for participants, families and support coordinators

Three people arrive at the same NDIS provider website.

A participant wants to know whether a service could suit them and what making contact will involve. A family member or trusted supporter wants to understand the provider’s approach, people and safeguards. A support coordinator wants to verify service scope, location, intake position and the correct way to discuss suitability.

They should not need three separate versions of the website. They should not have to choose an audience before they can browse. Nor should they encounter one vague page that says little beyond “we provide person-centred support”.

The planning question is:

How can one website give different readers the information and next steps they need without duplicating service content or fragmenting the organisation’s message?

Participants choose the providers they work with. A support coordinator may help a participant understand their plan, find possible providers and explore their options, but does not replace the participant’s decision. A plan manager has a different role centred on funding, claims, budgets and payments. Plan managers may need clear administrative information, but they should not automatically be treated as the main provider-selection audience.

A sound structure starts with shared facts, then creates different reading paths and next steps around them. This is the information-architecture layer beneath the broader website challenge facing NDIS providers: serving several audiences without fragmenting the message.

Start with the decisions people are trying to make

Audience labels are useful during planning, but real website use is driven by tasks. Participants may want exact information about service boundaries, prices and locations, while support coordinators need readable content they can explain or share. Much of the factual information is shared.

The sitemap should therefore be organised around service fit, practical access, getting started and operational tasks—not merely “participants”, “families” and “professionals”.

Model the information before drawing the sitemap

A sitemap maps pages. It does not define the information those pages must contain.

First establish the facts the organisation needs to maintain for each service:

• public-facing name and plain-language summary;
• what the support may involve;
• who it is intended for and important boundaries;
• relevant age groups or participant cohorts;
• locations, service areas and delivery methods;
• registration status or group where relevant;
• current capacity or intake status where it can be maintained;
• starting process and responsible contact;
• publishable funding, pricing, travel or cancellation information;
• related privacy, service-agreement, feedback and complaints information;
• internal content owner and review trigger.

Then separate relatively stable information from operational information.

Relatively stable information

• what the service is;
• who it may suit;
• its general delivery approach;
• important service boundaries.

Operational information

• current locations;
• capacity or waiting periods;
• available delivery modes;
• intake contacts and temporary changes.

Operational facts are the most dangerous to repeat manually. Writing “We currently accept enquiries in Logan and Ipswich” on the homepage, service page, location page and support-coordinator page creates four editing tasks and four opportunities for conflict.

The better model is to maintain the fact once, give it an owner and display it wherever needed.

Capacity information also needs a visible review process. A maintained notice could look like this:

Illustrative example: current intake position

Accepting enquiries for weekday community participation support in Logan. Limited availability in Ipswich.

Reviewed 10 August 2026.

When the organisation cannot reliably maintain location-level capacity information, a stable statement such as “Contact our intake team to check current availability by service and location” is safer than an undated “Now accepting referrals” banner.

Build one shared service architecture and a practical sitemap

For most providers, services should remain the website’s backbone.

A practical model uses:

• a service hub for browsing support types;
• one primary page for each service;
• audience pages that provide shortcuts, context or instructions;
• location pages where local availability genuinely differs;
• cohort pages only where the information substantially differs;
• search or filtering only when the service catalogue is large enough to need it.

The primary, or canonical, service page is the public source of truth. A service should not normally have separate participant, family and support-coordinator versions, plus near-identical suburb copies. They become inconsistent when scope, locations or contacts change.

A “For support coordinators” page can still collect intake information, service and location links, guidance on discussing participant fit and a printable operational summary. Its job is to route and assist—not reproduce the service catalogue.

Shared-content model: one maintained source of service information feeds the primary service page. That page then connects readers to the appropriate participant or family enquiry, support-coordinator suitability discussion, relevant location information, or plan-manager and accounts administration.

For a medium-sized provider, the sitemap might use the following structure. It is a starting point, not a universal template.

• Home
• Services
• Services overview
• Individual service pages
• Who we support
• Cohort or support-need pages, where genuinely useful
• Locations
• Service-area overview
• Individual location pages, where genuinely useful
• Getting started
• Looking for support
• What happens after contact
• Service agreements, fees and common questions
• For support coordinators
• Capacity or intake information
• Services and participant fit
• Discussing suitability
• About
• Organisation and approach
• Team
• Registration, safeguards and governance
• Feedback and complaints
• Contact

Services remain primary because people generally need to establish service fit first.

Who we support should earn its place. Create a cohort page only when it provides distinct, useful guidance—not a generic page for every diagnosis.

Location pages should reflect real local differences in facilities, teams, service mix, access or capacity. Avoid pages that change only the suburb name.

Getting started explains the process once, including initial contact, suitability discussions, assessments and service agreements.

Support-coordinator information should be prominent when coordinators are a substantial audience, while remaining useful to participants and families.

Feedback and complaints should be directly accessible, not buried inside About or a long policies index. The NDIS Commission says all providers are expected to have effective complaints practices, while registered providers must have a documented complaints management and resolution system. The website should make the pathway easy to locate, although a page alone does not satisfy those operational responsibilities.

Do not force visitors through a “choose who you are” opening screen. Audience shortcuts can help; audience gates can hide useful information.

Make each service page a shared decision page

This expands on the shorter service-page anatomy in our NDIS provider website design guide.

Consider a fictional provider offering individual community participation support. It may use an internal program name, but the public page should begin with an ordinary-language heading such as Individual community participation support.

1. Give a direct service summary

Individual community participation support helps people plan, practise and take part in activities in their local community, based on their interests, preferences and agreed support arrangements.

Immediately show maintained practical facts such as the general service area, delivery setting, relevant age range and current intake position. Ask whether this service may suit you is more informative than Contact us.

2. Explain who it may suit—and the boundaries

Describe needs or goals the service commonly supports without promising eligibility or outcomes. State relevant age or location criteria, important exclusions and circumstances in which another service may be more appropriate.

3. Show what support can look like

Concrete examples clarify an abstract service:

• planning and attending a local activity;
• practising a public-transport journey;
• becoming familiar with a community venue;
• establishing a routine for joining a regular group.

4. Bring delivery information together

State where, when and how support is delivered: in the home, community, centre or remotely; individually or in groups; within which service areas; under what scheduling or travel conditions; and with what current capacity, if maintained.

5. Explain who may deliver it

Provide relevant information about worker roles, qualifications where applicable, supervision and matching. Specific facts are more useful than claims such as “highly trained” or “industry-leading”.

6. Put communication and safeguards in context

Explain how participant preferences and communication requirements inform the service, how supporters are involved at the participant’s direction and where feedback or concerns can be raised.

The rights and responsibilities section of the NDIS Practice Standards includes expectations for registered providers relating to understandable communication, informed choice, privacy and dignity. Those principles can inform website structure, but they do not prescribe a sitemap or page layout.

7. Give accurate fees and service-agreement context

Publish only information the organisation can keep current. Explain where readers can find relevant prices, travel and cancellation details, and when payment arrangements are discussed.

An NDIS service agreement commonly records what support will be provided, how and where it will be delivered, costs and payment arrangements, responsibilities, changes and what happens when there is a disagreement. Written service agreements are not mandatory for most NDIS supports, although the NDIA recommends creating one when a participant starts working with a new provider. They are mandatory for specialist disability accommodation supports.

The website need not reproduce the agreement, but should explain where it enters the process.

8. Describe what happens next

Use the provider’s real process, for example:

1. initial question or enquiry;
2. discussion of needs, preferences and apparent fit;
3. any assessment or intake step;
4. confirmation of availability and proposed arrangements;
5. service agreement or commencement information.

The same fact can help different readers make different decisions.

Service area

• A participant needs to know whether support is practically available.
• A support coordinator needs to avoid exploring an option outside the participant’s location.

Delivery method

• A participant needs to understand what receiving support may involve.
• A support coordinator needs to assess whether the model appears to align with the participant’s preferences.

Current capacity

• A participant needs to decide whether making contact is worthwhile now.
• A support coordinator needs to judge whether a timely discussion is possible.

Service boundaries

• A participant needs to avoid false expectations.
• A support coordinator needs to assess apparent suitability before further discussion.

Create different entry points and operational pathways

Participant and family entry points might say Explore our supports, Find out how support starts, Ask a question or Talk with someone about your options. They should not assume everyone is ready to apply or book an assessment.

Support-coordinator pathways might say Check services and locations, View current intake information, Discuss whether a service may suit a participant or Find the service contact. The wording should preserve participant involvement rather than imply that the coordinator chooses on their behalf.

Many visitors arrive directly from search results or shared links. Every major landing page should explain what it covers, where key details sit and what the reader can do next.

Both participant-facing and professional pathways need direct language and accurate detail.

The contact method should then match the action. A single generic form often conceals several different operational processes.

Participant or family enquiry

The first step should allow a low-commitment question, explain what happens next and offer suitable communication options. It should not demand extensive personal or clinical information before the organisation needs it.

Support-coordinator suitability discussion

The pathway should reach the correct service contact, distinguish a capacity check from formal intake and identify useful preliminary information. Contact should not be treated as participant consent or a completed referral.

Plan-manager or accounts administration

Invoice, remittance, payment and account questions should have their own route rather than entering the service-enquiry queue.

Someone checking whether a service operates locally should not need a long referral form. A coordinator checking capacity should not have to pretend to be the participant, and an accounts officer should not enter a service-enquiry queue.

Ask only for information needed at that stage, explain why it is requested and state what happens after submission. There is no single referral form that will suit every provider and service. The fields should follow the organisation’s real service and intake process.

Put trust and governance information where decisions happen

Do not confine trust content to a large About page.

Near a service decision, readers may need to find:

• registration status and relevant scope, where applicable;
• who delivers or supervises the service;
• service boundaries and communication options;
• privacy information;
• feedback and complaints pathways;
• service-agreement information;
• what happens when the service is not a suitable fit.

The applicable NDIS Practice Standards relate to registered providers. The NDIS Code of Conduct applies more broadly to registered and unregistered providers and their workers. A website should therefore describe registration accurately rather than implying every provider, service or location has the same status or scope.

Replace slogans with evidence. Instead of leading provider, state the relevant service scope. Instead of we go above and beyond, explain the response or supervision process. Instead of we treat everyone like family, explain how preferences, privacy and participant decision-making are respected.

Common structural failures—and better alternatives

Design the CMS and governance around the architecture

Useful structured fields may include service summary, participant fit, boundaries, age range, linked locations, delivery methods, intake status, registration information, service contact, related services, last operational review and content owner.

The principle is to model reusable facts once, then let templates display them in the relevant places.

Governance must answer practical questions: who may change registration and scope information; who owns capacity updates; what triggers review; which pages a location change affects; and whether precise waiting times should be published if nobody can maintain them.

When a service stops accepting enquiries in one region, the update may need to affect its service page, location page, directory, support-coordinator hub and form options. A structured system can update these relationships together. An unstructured system depends on somebody remembering every place the region was typed.

Templates should create consistency without forcing every service into identical copy. Services may share fields and page logic while needing different explanations and safeguards.

Test the structure with real tasks, then run a self-audit

A sitemap often looks logical to its creators because they already understand the organisation. Test it with people who do not.

Participant scenario

Ask someone to find whether a support appears relevant, whether it is available locally, what receiving it may involve and what happens after an enquiry.

Family member or trusted supporter scenario

Ask them to find how the participant is involved, who may provide support, how communication works and how to raise concerns.

Support-coordinator scenario

Ask them to find the exact scope, participant fit and boundaries, delivery area, intake status if published and the correct suitability contact.

Plan-manager or accounts scenario

Ask them to find the invoice or payment contact without entering the referral pathway.

Observe more than successful completion. Record misunderstood labels, expected pages people cannot find, repeated searches, uncertainty, conflicting facts and forms people are reluctant or unable to complete.

Include people with disability in testing and provide the communication methods required for meaningful participation. Detailed WCAG and assistive-technology testing belongs in the broader accessibility process; this exercise tests whether the information architecture makes sense.

Use the following questions to assess the proposed structure:

• [ ] Can someone understand each service without knowing internal terminology?
• [ ] Does every service have one primary source of accurate information?
• [ ] Can participants, families and support coordinators reach the same facts from suitable entry points?
• [ ] Are audience pages routing pages rather than duplicate catalogues?
• [ ] Does the website distinguish support coordination from plan management?
• [ ] Are service areas, delivery methods and participant-fit information easy to find?
• [ ] Do enquiry, suitability and accounts pathways reach the correct people?
• [ ] Does each pathway explain what happens after contact?
• [ ] Is registration status described accurately and only where relevant?
• [ ] Are feedback, complaints and privacy information easy to locate?
• [ ] Can operational information be updated from one reliable source?
• [ ] Has the structure been tested through realistic tasks?

One coherent website, several useful paths

The goal is not to make visitors identify their audience category before they can use the website. It is to make accurate service information understandable from different starting points.

That requires one reliable body of service information, navigation based on real tasks, useful audience entry points, distinct enquiry and administrative pathways, and a content system that keeps operational facts aligned as services change.

One coherent website should allow different people to find the same reliable facts, understand them in context and take the next step appropriate to their role.

Relevant guidance checked

This article provides website-planning information, not legal, registration or compliance advice. Official guidance was checked on 13 August 2026. Providers should confirm which obligations apply to their registration status and services.

• What is a support coordinator? — NDIS
• What is a plan manager? — NDIS
• NDIS Practice Standards — NDIS Quality and Safeguards Commission
• NDIS Code of Conduct — NDIS Quality and Safeguards Commission
• Complaints about supports and services you provide — NDIS Quality and Safeguards Commission
• What is a service agreement? — NDIS