Platform owner. Your handover

InstitutionsLast updated: 13 Aug 20269 min read

You are the dedicated staff member who will run First Six day to day. Usually a student-success, engagement, or wellbeing lead, sometimes a team lead with one or two responders alongside you. This document covers the path from your very first sign-in through to the point where the in-product launch checklist takes over.

Your progress0 of 0 tasks

What's already done for you

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

Provisioned your institution's tenant in our Sydney database.
Created your staff row with the institution_admin role.
Wired your IdP for sign-in (your IT team owns the configuration; see IT and SSO).
Set your institution's brand. You set the visuals yourself at Settings → Brand identity: your one accent colour and your logo, with a live preview; saving re-themes the apps with no redeploy. Dark mode is derived for you (the apps brighten your accent for dark backgrounds). The email sender address is the exception (it needs your domain verified with our mail provider first, so raise that with us). Your institution name and short name you also edit at Settings → Institution.
Stood up the crisis-response plumbing. You point it at your institution's actual on-call response in step 7 of the launch checklist; we built the pathway it runs along.

Everything past that point is yours to drive. Tick items off as you complete them. Progress saves in your browser.

You'll sign in via your institution's SSO at https://console.firstsix.com.au. The very first time you sign in to a brand-new instance, First Six doesn't drop you into an empty console: it sets the instance up with you first. By default a short concierge conversation asks a handful of questions (in plain language, with quick options to tap) and configures the essentials from your answers, then shows you a summary to confirm before anything is applied. Prefer to click through it yourself? Choose Set it up manually for the same choices as a one-decision-at-a-time wizard. Either way you can't skip it, on purpose: it makes sure the instance is set up properly before a single student arrives, and it only covers the few things First Six genuinely can't run without. Everything else waits for the checklist afterwards.

Choose how your students start. The first decision, because it shapes everything after it: a single shared intake (everyone on the same six-week arc), individual start dates (each student's six weeks runs from their own date), or rolling terms (multiple overlapping terms at once). You can change it later.

Name your first intake. The wizard creates your first cohort here (name, start date, length), so you don't have to hunt for the Cohorts & Student Import page. If you chose rolling terms, it takes you to the term calendar straight after to set up your terms and units.

Check who gets told, then widen it. Settings, Crisis opens with a panel called Who gets told. It names the actual people a crisis alert would be emailed to right now, read from the same list the alert itself uses, so it cannot flatter you. Read it before anything else on that page.

Two things it will tell you, and both matter more than they look:

How many people. Alerts go to everyone holding the crisis-response permission. On a brand new tenant that is often just you, and one person is not a rota: you sleep, take leave, and eventually move on. Give at least one colleague the permission in Team before students arrive.
How many routes. Email is the baseline and it is always on. If it is the only route, a delayed or filtered message is a silent failure. Adding a Slack or Microsoft Teams webhook, or a crisis help-desk queue, gives the alert a second way out. Both are optional and both run in parallel with the email, not as a fallback after it fails.

Then send a real test and confirm it lands, rather than assuming it would.

When you land on Home, confirm the footer of the left sidebar shows your name and the role "Institution admin". If it shows a different role, ask us; your permissions will be wrong until that's corrected.

The setup wizard only runs once, and only for you

It runs on a fresh instance until you finish it, then First Six takes you straight to Home on every later sign-in. Colleagues you invite afterwards (content editors, support responders) never see it: they join an instance you've already set up, and get the lighter Staff Tour instead.

After setup: the launch checklist

The moment you finish the wizard you land on Home, and the Get your cohort ready card appears at the top showing your progress. That card is the in-app launch guide and is the source of truth for everything that comes next: importing your students, authoring the six weeks, inviting your team, and polishing your branding. It auto-detects each step as you complete it, and you can leave and come back over days, it holds your place.

A guided walkthrough runs the first time

The first time you reach the console (right after the setup wizard), a short interactive tour steps you through each surface: Home, the Inbox, where you build the six weeks, your students, and the cohort pulse. If you chose rolling terms it also points you at the term calendar. It takes under a minute and you can skip it at any point. When you finish the walkthrough, your Get your cohort ready companion opens on its own and follows you around the console, so your next step to go-live is always one glance away. (Skip the tour and nothing is forced: you can still open the companion any time from Home or Guides.) To see the tour again later, use Replay product tour on your account page (Your account, from the identity row at the bottom of the sidebar).

On Home, confirm the launch card appears and shows "0 of N" done.

Run the in-product launch guide

The 10-step guide is grouped into three:

Set up your cohort (steps 1–4)
Term dates, brand verification, importing students, and confirming the audience tags that come out of the import. Get the dates right on the first pass. Every weekly date range computes from semester_start, so changing them later means rewriting six weeks of content by hand.
Build your content (steps 5–8)
The six-week arc, events, student resources (links, Ask Anything, help routes), and campus maps. (The weekly check-in question is standard and comes ready-made; there is nothing to write for it.) This is the bulk of the work. The crisis help route (step 7, inside Student resources) is a hard prerequisite for going live. See the safety-net guide for the detailed walkthrough.
Launch (steps 9–10)
Add your responders + content editors to the Team (for a whole team at once, use Import from CSV rather than inviting one by one), double-check week one's audience targeting, then publish week one. The moment Week 1 is published, any student who signs in sees it. That's go-live.

Click into the launch card on Home and skim all 10 step titles so you know the shape of the work ahead.

Step 1: term dates set.Step 3: students imported. (Step 2 is a brand verification. Quick.)Step 4: audience tags confirmed.Steps 5–6: six weeks of content + events. (The check-in question is standard, nothing to write.)Step 7: student resources curated, including the crisis help route.Step 8: campus maps uploaded.Step 9: at least one responder added.Before publishing: week one's audience targeting double-checked across your student groups.Step 10: week one published. Cohort is live.

Don't skip the targeting check

Reading week one back and confirming every item's audience targeting, before you publish, is the only place you'll catch tone-of-voice misses, an item aimed at the wrong students, or a help route that points nowhere. The platform can't tell you whether your what-matters block reads kindly to a first-in-family student; only you can.

After go-live: the ongoing rhythm

Once the launch checklist retires, your weekly cadence is roughly:

Daily: glance at the Inbox. Triage any help requests that haven't been picked up by a responder. The crisis pathway already paged you (and the wider responder pool) the moment one was flagged; the Inbox is for the rest.
Weekly: review the cohort Pulse (under Insights). It's a small-N-suppressed read of the weekly check-in. Calm signal, not surveillance. If a week trends low, that's the week to surface extra support.
Weekly: publish the next week's content. The 6-week arc is authored up-front but each week's blocks should still be reviewed before they go live.
Per term: roll the cohort over (use the roll-a-cohort-over guide) and re-confirm dates / events / audience tags.

See what your students see

On the Cohort page, Preview as a student opens the student app in a new tab, signed in as a stand-in student in this cohort, so you can walk your real weeks, events and check-ins exactly as a student would. It is time-limited and tenant-scoped, the stand-in is hidden from your rosters and Insights, and it can never send an email or trigger an alert, so nothing you click there reaches a student or your reports.

Set a daily reminder to check the Inbox.Set a weekly reminder to review the cohort Pulse.Set a weekly reminder to publish the upcoming week.

When to ask for help

You can email support@firstsix.com.au for anything from "how do I…" through to "the SSO isn't working for one student". Email support@firstsix.com.au; we respond within one business day. We aim to respond the same business day, and crisis-pathway incidents come first. (Security disclosures follow our published policy: acknowledged within two business days.)

For the cyber team's pre-launch sign-off, point them at the cybersecurity and privacy handover. For SSO and integrations work, your IT team should be working from IT and SSO. For the executive sponsor's view, Leadership and sponsor.

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 very first sign-in

After setup: the launch checklist

Run the in-product launch guide

After go-live: the ongoing rhythm

When to ask for help

Related