Leadership and sponsor. Your handover

InstitutionsLast updated: 13 Aug 20264 min read

You are the executive accountable for the First Six rollout. Typically a Director of Student Experience, Head of Wellbeing, DVC Students, or equivalent. Your job here is decision and comms, not configuration; the platform owner, IT, and cyber teams handle the build. This document is short on purpose.

Your progress0 of 0 tasks

What's already done for you

By the time you reach this page, First Six has:

Sold you a working product, not a build commitment. Every feature exists and is wired up.
Provided the evidence pack your cybersecurity and legal teams need (see the cyber and privacy handover).
Stood up a working tenant in our Sydney database, ready to receive your roster and content.
Documented every visible cost, gap, and risk openly, not buried in page 80 of a PDF. The full HECVAT self-audit, the risk register, and the subprocessor list are all in plain text and dated.

Your handover checklist

Read the cyber and privacy handover or have your cybersecurity team's lead summarise it for you. You shouldn't sign off the procurement without knowing what's on the "things we don't have yet" list (no SOC 2, no penetration test; the the institution DPA template is signable and has been since 13 July 2026, but it is reviewed in-house rather than by external counsel, and no institution has executed one yet. These are all stated openly).

Agree the internal comms plan with whoever runs student-facing communications at your institution. The phrase to anchor on: First Six should land as a welcome, not a surprise. Students who get a note from a known institutional voice ("this is the platform we use to look after you in your first six weeks") engage far better than students who get a sign-in link from an unknown sender.

Sign off the crisis responder chain the platform owner has configured (under Library → Help routes). The platform pages your team in parallel. Email always, plus Slack or Teams where you've connected them; the actual pathway it follows is your institution's protocol. You own that protocol, even though the platform owner configured it.

Agree what success looks like for the first cohort with your platform owner. Sensible starters: weekly check-in response rate (Insights → Pulse) and help-request resolution time (the support-for-students evidence pack). A content-engagement view is on the roadmap. Neither of these is a vanity metric. They tell you whether the platform is doing what it was bought to do.

Know two contacts at First Six: support@firstsix.com.au for day-to-day, and connor@firstsix.com.au for escalation. We're a small team. Escalation is short.

Make the explicit go-live decision when the platform owner reports the launch checklist is at 12/12 and cyber has signed off. The platform doesn't auto-launch; someone has to say yes. That's you.

What you don't need to touch

To be clear about scope, these are not on your list:

The day-to-day platform operation (platform owner).
The technical SSO / SIS / calendar integrations (IT team).
The HECVAT / DPA / breach-response review (cyber and privacy).
The weekly content writing (platform owner or content editor).
The student help-request triage (platform owner / responder pool).

You can ask about any of these. You don't need to drive any of them.

The 30-second sponsor's brief

If you need to explain First Six to a peer in 30 seconds: "It's the six-week onboarding platform we run on student SSO. Students get a weekly briefing, a check-in, an inbox to ask for help, and the staff team gets early-warning signal on who's struggling. All data hosted in Sydney, fully privacy-reviewed, calm by design."

What to escalate to us

You don't need to chase us for routine matters. The platform owner does that. Escalate to connor@firstsix.com.au if any of these happen:

A privacy or security incident materially affects your institution.
A subprocessor change or region change is announced and you have questions beyond what the change notification covers.
The platform owner reports being structurally blocked by us (rare; usually it's a config they can clear themselves).
You're considering ending the engagement and want a data-export + off-boarding conversation.

Was this helpful?

Need more help?

The fastest answer is usually one question away.

Edit this page on GitHub

What's already done for you

Your handover checklist

What you don't need to touch

What to escalate to us

Related