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.
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.
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.
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
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
A reminder from your CRM
One extra email a few days after acceptance, with the same link.
- 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.