The platform

Everything connected to the work around it.

The short version is on the home page. This is the depth beneath it — what a person record actually holds, how individual and group delivery is recorded, how communication keeps its context, how internal work moves, how forms and funding adapt as your services do, what a health and wellbeing service looks like inside it, and what each role sees when they open the platform.

People, families & the service journey

Understand the whole journey.

One person, one record — from the referral that started it to the note somebody wrote this morning. Family, whānau and aiga relationships are held on the record too, so a worker picking it up sees who else is in the picture rather than piecing it together from memory.

  • Person profile
  • Family, whānau and aiga relationships
  • Referrals
  • Timeline
  • Notes
  • Documents
  • Plans
  • Goals
  • Appointments
  • Programme participation
  • Communication history

See the person, not just the service.

Communication history is part of that record, not a separate inbox. Every message stays connected to the person, programme, service, referral or session it belongs to — so the timeline shows not only that somebody was contacted, but what the contact was about.

Individual & group service delivery

One person at a time, or a whole community at once.

Some of the work is a home visit. Some of it is sixty people in a hall on a Saturday. Both are service delivery, both count towards a contract, and both are recorded properly here.

  • Individual appointments
  • Navigation
  • Home visits
  • Outreach
  • Programmes
  • Group sessions
  • Community events
  • Enrolment
  • Waitlists
  • Group and individual notes
  • Follow-up

Three ways to take attendance

Attendance is where group delivery usually breaks down: a system that only knows how to tick names off a list cannot record a community event, and one that only counts heads loses the people in a programme. TeAlaOla supports all three, chosen per session.

Named attendance

Every participant marked individually. This is the mode for a programme cohort, a course or a support group, where who was in the room is the point.

Aggregate attendance

Totals and demographics only. A community day with three hundred people through the gate is counted honestly, without pretending each one was enrolled.

Hybrid attendance

Both in the same session. Enrolled participants are recorded by name, everyone else is counted — one session, one record, no double entry.

Enrolment and waitlists sit alongside the session itself, and notes can be written for the group as a whole or for one participant privately. Follow-up is raised from the session it came out of — nobody has to remember to go somewhere else and do it again.

Communication & engagement

Stay connected without losing context.

Messages are sent from the same place the work is recorded, so six months later nobody has to guess why a person was contacted or which programme a reminder came from.

  • Individual SMS
  • Bulk SMS
  • Individual email
  • Bulk email
  • In-app messaging
  • Appointment reminders
  • Programme reminders
  • Service follow-ups
  • Automated surveys
  • Feedback requests
  • Person communication

    Every message a person has been sent or has replied to sits on their record, in order, alongside the rest of their history.

  • Programme communication

    Session reminders and cohort updates stay attached to the programme that sent them, so a programme lead can see what their group has heard.

  • Service communication

    Follow-ups, surveys and feedback requests carry the service, referral or session they came out of — the reason for the contact travels with it.

Communication stays connected to the work around it.

Internal tickets, tasks & workflow

Keep internal work moving.

Plenty of what an organisation does is not service delivery but still has to happen — an administration request, a documentation chase, a finance question, evidence a contract needs. Tickets keep that work visible without leaving the platform the service runs on.

  • Administration requests
  • Participant follow-up
  • Programme actions
  • Documentation requests
  • Finance questions
  • Contract evidence requests
  • Service requests
  • Internal operational issues

A ticket carries who asked, who owns it and when it is due — and, because it lives beside the work, what it is about.

  • Requestor
  • Assignee
  • Team
  • Priority
  • Due date
  • Status
  • Comments
  • Attachments
  • Related person
  • Related programme
  • Related service
  • Related contract

The lifecycle

  1. New

    Raised by anyone, with the person, programme, service or contract it relates to.

  2. Assigned

    Given an owner and a team, with a priority and a due date.

  3. In Progress

    Being worked, with comments and attachments kept on the ticket.

  4. Waiting

    Blocked on somebody else, and visibly so rather than quietly stalled.

  5. Completed

    Closed, with the trail of what was asked and what was done still attached.

What a manager sees

  • Open tasks
  • Overdue requests
  • Work by team
  • Completion rates
  • Request categories
  • Response and resolution trends

Worth being clear about what this is. These are simple internal workflows connected to service delivery — not an enterprise IT ticketing product. The value is that a documentation request sits next to the person it concerns and the contract it feeds, not that it has a service catalogue and an escalation matrix.

Forms, automation & flexibility

Adapt as your services change.

New contracts, programmes and reporting requirements should not always require new software development. Forms, fields, statuses and follow-up are configuration — a new intake form or a new outcome measure is an afternoon's work for your own team, not a release from us.

  • Dynamic custom forms
  • Intake forms
  • Consent forms
  • Assessments
  • Programme forms
  • Outcome forms
  • Surveys
  • Sections
  • Conditional fields
  • Show, hide and require rules
  • Versioned definitions
  • Configurable fields
  • Configurable statuses
  • Service-specific workflows
  • Custom screens where supported
  • Automated reminders
  • Automatic follow-up surveys

Capture what this service needs

Conditional fields mean a form asks the next question only when it is relevant, so an intake stays short for the people it should be short for. Statuses and workflows are set per service rather than shared across everything the organisation does.

Then let it run

Reminders and follow-up surveys can be attached to the thing that triggers them — an appointment, a session, the end of a programme — so the routine chasing happens without anybody holding a list of it in their head.

What holds when a form changes

A rule reads as a sentence

When this answer is that, show, hide or require this question — or a whole section of them. One flat condition per rule with no nesting and no precedence, so the person who wrote it can still read it back a year later.

Editing never rewrites an answer

Every response records the version of the form it was given against. Publishing a new version leaves the answers already collected meaning exactly what the questions asked at the time, so a form can be improved without corrupting the history behind it.

A submitted answer is final

Once a form is submitted its answers are frozen in the database itself, not merely in the screen that shows them. They can be superseded by a later answering, which leaves a trail — they cannot be quietly edited or deleted.

Build the information capture around your service — not your service around the software.

Funding, contracts & reporting

From the mahi to the claim, without typing it twice.

Delivery that has already been recorded is the same delivery that gets funded, evidenced and reported. Nobody rebuilds the month in a spreadsheet at the end of it.

  • Funders
  • Contracts
  • Funding lines
  • Service codes
  • Service units
  • Expenses
  • Billable activity
  • Invoices
  • Claims
  • Evidence
  • Xero connectivity
  • Contract targets
  • Outcomes
  • Reporting
  1. Activity

    The appointment, session or event that actually happened.

  2. Funding allocation

    Matched to the contract and funding line that pays for it.

  3. Billable unit

    Counted against the service code and unit the contract is written in.

  4. Evidence

    Notes, attendance and outcomes already recorded stand as the proof.

  5. Claim / invoice

    Claimed or invoiced, with Xero connectivity for the finance side.

  6. Reporting

    Rolled into contract targets, outcomes and the report a funder reads.

Contract targets sit against actual delivery, so a manager can see where a contract stands before the quarter closes rather than after it. Expenses and billable activity carry through to claims and invoices, and from there into your accounting system.

Connected to your Xero, not to ours

The accounting integration is your organisation’s own connection to your own Xero organisation, authorised by somebody at your end. A provider running two legal entities connects two Xero organisations, because reconciliation across a shared one is a problem nobody wants later.

  • Your ledger, your codes

    Your chart of accounts and tracking categories are mapped explicitly rather than assumed. A category with no account mapped holds its work in the queue instead of posting to a default and being discovered in an audit.

  • A claim reaches Xero once

    Every push carries an idempotency key, and dedupe is layered rather than trusted to one check — so a timeout, a rate limit or somebody pressing the button twice cannot post a second invoice.

  • Finance can see what happened

    Sync activity is a register your finance team reads on screen, with a reason and a retry against anything that failed. Nobody has to ask an engineer why an invoice did not arrive.

TeAlaOla does not do your accounting and does not want to. Invoices, bills, credit notes, payments and contacts cross between the two; your accountant keeps working in Xero.

Capture the mahi once. Use it for delivery, evidence, funding and reporting.

Health & wellbeing services

Wellbeing support, from the referral to the outcome.

Hauora providers, community health teams and whānau support services run on referrals, appointments, group programmes, notes and follow-up — and on being able to show a funder what changed. All of that is recorded here, against whatever wellbeing framework your organisation already works to, in the terminology and languages your organisation has configured. This is not a clinical system: there is no diagnosis, no medication, no clinical assessment and no health-record integration in TeAlaOla. It records the service, not the clinical care.

  • Inbound referrals
  • Referral source
  • Intake and triage
  • Urgency and risk flags
  • Waitlists
  • Appointments
  • Home visits
  • Programmes and sessions
  • Named, aggregate and hybrid attendance
  • Individual and group notes
  • Consent by purpose
  • Documents on file
  • Whānau and aiga relationships
  • Preferred language
  • Accessibility and cultural requirements
  • Restricted records
  • Outcome measures
  • Billable activity
  • Referral first appointment

    A referral from a GP practice, a hospital team, a marae, a school or another agency arrives with the referrer’s own account of why — kept word for word — plus how quickly it was sent, the language the person prefers and the access and cultural needs that come with them. Triage moves it across a board, and the appointment that follows stays attached to it.

  • Session everyone in it

    A group programme takes attendance by name, by headcount, or both in the same session. The note is written once and lands on the session and on each participant’s own file, and the billable activity comes off that same session against the service code the contract is written in.

  • Person whānau

    Household, whānau, aiga, extended and kin relationships are held on the record, and consent is recorded explicitly against the purpose it was given for. A record marked restricted is not greyed out for the staff who should not see it — it is absent from the search, the list and the count.

Wellbeing measured against your framework, not a model we chose for you.

Dashboards & reporting

The right view for every role.

A dashboard can be built around the service, role, team, programme, site, contract, funder or organisational framework it needs to describe — so what somebody opens first is the work actually in front of them, backed by up-to-date operational reporting.

  • Service
  • Role
  • Team
  • Programme
  • Site
  • Contract
  • Funder
  • Organisational framework

Frontline teams

Referrals, caseload, appointments, tasks and follow-up.

Programme teams

Sessions, enrolment, attendance, engagement and outcomes.

Managers

Service demand, workload, KPIs, performance and contract delivery.

Leadership & governance

Organisation reach, outcomes, funding performance and strategic KPIs.

Supported across every view

  • Live operational KPIs
  • Filters
  • Drill-down
  • Saved views
  • Configurable widgets
  • Manager-customisable dashboards
  • Role-based permissions
  • Reporting
  • Export

A view for the Board

Governance can be given a view of its own. An authorised external user — a Board Chair, a governance representative — can receive controlled dashboard access without unnecessary access to operational records or participant information.

One view of a single programme

A programme coordinator opens one screen rather than eleven tabs: enrolment and waitlist, sessions delivered, the attendance trend, who is taking part, the referrals feeding it, the outcomes recorded against it, and where it sits on its funding and its spend.

What somebody sees depends on what they may see. A coordinator without contract access gets a dashboard with no funding section at all rather than one showing zero — a blank where a number should be is worse than an honest absence. Reported attendance figures come from the sealed session record and are never recomputed underneath a report that has already gone out.

From frontline action to Board-level insight.

Ask your data

A question in plain words, and the query it built.

Most of the questions a manager has are small, specific and urgent — how many, in which programme, since when. The data explorer takes them in ordinary language, builds a query against a published set of read-only views, shows you that query in words, and then runs it. Reading the query before the answer is the whole design: if the question was understood wrongly, that is where you see it.

  • People
  • Contact points
  • Programmes
  • Sessions
  • Attendance
  • Enrolments
  • Contracts
  • Funding lines
  • Framework tags
  • Form response metadata
  • Message metadata
  • Staff
  1. The question

    Asked in ordinary words by somebody who holds the capability to ask.

  2. A plan

    Built against the published views, and shown in plain language before anything runs.

  3. Or a question back

    An ambiguous question is returned as a question rather than answered with a guess.

  4. A read

    Compiled to a parameterised query and run read-only, inside your organisation’s own data.

  5. On the record

    The question, who asked it and what came back are kept — including refusals.

Where it is fenced

Each of these is a mechanism rather than a policy — a database privilege that was never granted, a view that does not exist, a dependency the build refuses to allow. They hold whether or not the question was asked in good faith.

It builds a plan, not SQL

The model never writes a query. It fills in a structured plan against the catalogue above, and the platform turns that into a parameterised read. Every column name that reaches the database comes from a file we wrote — no output from a model can invent one.

It runs as a login that cannot write

A separate database role with SELECT and nothing else: no insert, no update, no delete, no schema change, anywhere in the database. It also cannot bypass row-level security, so it is confined to your organisation by the same rules that confine the application itself.

Free text is not in reach

Notes, assessments and the contents of messages are not in the catalogue. Form answers are reachable as metadata — that a form was completed, when, against which version — never as the words somebody wrote. This is absence, not filtering.

It cannot contact anybody

A saved report can become a communication audience, but only by a person choosing to, and the send then runs the same consent, contact and language checks every other campaign runs. The reporting side holds no reference to the sending side at all, and an automated test enforces that.

Answers from your own records, inside boundaries you can see.

See it against your own services.

The quickest way to know whether this fits is to walk one of your services through it with us. Bring a contract, a programme and the report you dread writing.