Arrival

For admissions, IT and data teams

How Arrival fits in.

Three phases, from offer to the end of the first year. No IT project and no student data to start. Nothing connects to your systems unless you want it to.

  1. 1From offer to arrival

    Admissions

    You
    Add one line to the acceptance email you already send: a personal link, with each student’s applicant ID filled in by your CRM, the way it fills in their name.
    We
    Set each student up when they tap it, and match them to your records by applicant ID. Each student tells us whether they live in the country already, so home students never see visa or travel steps.
  2. 2At enrolment

    Enrolment

    You
    Nothing. Students keep the account they made. If a student’s plans change, withdraw them in the portal.
    We
    Flag the students who may not arrive, weeks before enrolment day: no visa, no flight, or gone quiet.
  3. 3The first year

    Every office

    You
    Give us what each office already sends new students, such as accommodation, IT, fees and wellbeing: emails, PDFs and web pages.
    We
    Set it up as steps and messages timed to each student’s arrival, and give each office its own login, which sees only its own steps.

Applicants through UCAS

The same link works. Put it in the email you send when a student makes you their firm choice, again at Confirmation, and in your Clearing confirmation, with their UCAS Personal ID or your own applicant number.

The link itself

arrivaledu.com/join/intake code?ref=applicant ID

Each intake has its own code. Each applicant ID can be claimed once; a second claim is flagged for your team to check.

Overleaf: reminding offer-holders, full integration, and your data.

Not everyone clicks the first email.

Three ways to remind offer-holders, easiest first. Use any or all of them.

  1. 1

    Put the link in every email

    The same line in the footer of everything you already send offer-holders: accommodation, fees, enrolment. Every email becomes a reminder.

  2. 2

    A reminder from your CRM

    One extra email a few days after acceptance, with the same link.

  3. 3

    We remind them for you

    Upload your list and we email anyone who hasn’t joined the day after, in your name. Nobody who has joined is emailed.

The first two need no student data from you. The third needs names and emails, which reach us as your data processor, under our data processing agreement, and are used for nothing else.

Want it connected? Full integration.

An add-on, set up with your IT team. Every connection uses one student data feed, whatever your systems: SITS, Banner, Salesforce, Dynamics, Slate or your own. You send to us; we never need access to your systems.

  • Your CRM sends each accepted student to us automatically
  • Students sign in with your university login
  • Enrolment status and student numbers come from your records system
  • Office systems tick off steps, such as a room accepted
  • Updates land back in your CRM: joined, gone quiet, at risk

Your data.

What you send us
Nothing, to start. Students give us their own name and email when they sign up.
Who is responsible
You are the data controller; we process on your behalf, under our data processing agreement.
Where it’s held
In London. Email is sent from Dublin.
Who sees what
Your team sees progress and arrival steps, never what a student asks Ari or the documents they keep.
Getting it back
Export every student and their progress at any time.

Download as a PDF · Security