Home · Solutions · Sales & marketing · Course enrolments, contracts and instalments
Solution · Sales & marketingThe student enrols in the evening, signs before bedtime, and a robot remembers the instalments
Course enrolments, contracts and instalments
A robot reads the enrolment form, checks free places in the group, builds the contract from your template and sends it for signature within minutes. Instalments land in a register, reminders go out before the due date and payments from the bank export tick themselves off. The office steps in only for discounts, transfers and conversations with parents.
Executive summary
Today every enrolment is a form or a phone call, data retyped into a spreadsheet, a contract patched from last year’s template and instalments entered separately; with a two-person office, September means three weeks of overtime.
A robot reads the submission, reserves a place in the group, merges the data into the contract and sends it for e-signature; the instalment schedule sets itself up and the reminder goes out before the due date, not a month after.
The contract reaches the student in minutes instead of days, so fewer enrolments die in transit; typos and wrong groups stop producing annexes, and arrears are visible daily rather than at a quarterly review.
enrolment form and group register; contracts from your template to e-signature; instalments watched from the bank export; summaries in Microsoft Teams
Business problem
September lasts three weeks, the fatigue lasts until December
A language school with three hundred and forty students relives the same September every year. Each enrolment is a form or a phone call, data retyped into a spreadsheet, a contract patched together in a word processor from last year’s template, a printout or a scan, a signature, and an instalment schedule entered separately. With a two-person office that is three weeks of late evenings, and a second, smaller peak waits in February.
The errors come from retyping. A surname travels from the form to the contract, from the contract to the instalment sheet, from the sheet to the group register; four transcriptions are four chances for a typo, and a typo in a contract means an annex, a printout and a second signature. Worse happens too: a student placed in the wrong group notices at the second lesson, and the instalment has to be recalculated, because B2 costs more than A2.
Instalments lead a life of their own. One student pays in two instalments, another in eight, some by transfer, some in cash at the front desk. Who is behind only shows when someone sits down with the bank statement and the spreadsheet at once; in practice once a month, so the reminder about a September instalment can go out in November, which is awkward for both sides.
Yet nine enrolments in ten are mechanical: check the place, merge the data into the template, price the instalments from the list. That is work for a system, not for an office at 9:30 pm. The human part begins where a parent asks whether their son really belongs in B1, and nobody wants that part automated.
How it works today
Below is what the work looks like before anything is automated.
- PersonThe enrolment arrives by form or phone, mostly in the evening and in September
- Risk of errorThe office retypes the data into a spreadsheet and hunts for a group with space
- Risk of errorThe contract is built in a word processor by swapping data in last year’s template
- WaitingThe printout waits for a signature until the next visit, sometimes two weeks
- Risk of errorThe instalment schedule is entered separately into the payments sheet
- WaitingArrears surface at the monthly statement review, not earlier
Why the current process costs more than it appears
The bill that never shows up in a budget.
- A full document set per student takes fifteen to twenty-five minutes today; multiplied by hundreds of enrolments that is weeks of work.
- A contract that travels for days loses to a competitor’s contract sent in fifteen minutes; part of the enrolments die in transit.
- Every retyping typo is an annex, a printout and a second signature; every wrong group means recalculating instalments.
- A reminder sent after the fact means the school’s cash sits in students’ accounts for weeks.
Cost of inaction
The estimate assumes 340 enrolments in September, 140 in February and 25 minutes per set: data, contract, instalments. You will know your own numbers after one measured season.
The most expensive line sits outside the table: the student who never enrolled because your contract took a week while the school across the street sent theirs in fifteen minutes.
A model organisation with realistic proportions – the numbers exist so you can run the same maths on your own data; they are not a client result.
A language school in a county town: 340 students, 24 groups, a two-person office, enrolments by form and phone, contracts in a word processor, instalments in a spreadsheet, Microsoft 365.
About 480 enrolments a year in two peaks; the document set takes 25 minutes on average; instalment reminders go out whenever someone finds time for the statement.
Tuesday, 7:40 pm: the mother of an eight-year-old fills in the form for a children’s A1 course, Tuesday-Thursday group, payment in eight instalments.
The robot checks the register, reserves one of three free places, builds the contract with the data, level and instalment schedule and sends it for e-signature; the mother signs on her phone before bedtime stories.
The signed contract lands in the group’s SharePoint folder, the instalments in the payment register; three days before each due date a reminder goes out with the account number, and the payment from the export ticks the instalment off by itself.
In the morning the office sees in Teams: seven new enrolments, six contracts signed, one pending. In the modelled year the document set falls from 25 minutes to exceptions. These are model figures, not the school’s records.
Proposed solution
We start with your contract template and price list: the robot works on the document your lawyer drafted, we only turn the data fields into merge fields. An enrolment form in Microsoft Forms or on your website collects the student’s data, level, group and instalment count; from then on the form is the single source, so four transcriptions and four typo chances disappear.
The robot checks free places in the group register and reserves a spot, or proposes an alternative when the group is full. The contract with data, price and instalment schedule goes out for e-signature within minutes of the submission; signed, it returns to the group’s SharePoint folder. The document-reading layer handles scans when someone prefers paper after all.
The instalment register watches itself: a reminder before the due date, matching of payments from the bank export by transfer title, ticking the instalment off, and on arrears a calm message to the student plus a note for the office. You decide the tone and frequency of reminders; the robot escalates nothing and runs no debt collection, it just keeps the calendar.
UiPath Orchestrator: the enrolment queue, instalment reminder schedules, retries and an audit trail; UiPath Integration Service connectors to Outlook 365, SharePoint and Teams; document reading for signed contract scans
An enrolment form wired to the group register, contracts generated from your template, instalment schedules, pre-due-date reminders, payment matching from the bank export and a morning summary in Teams
The group and student register (a spreadsheet or a SharePoint list); the bank statement via CSV or MT940 export; an SMS gateway and e-signature on your own provider contracts
How the automated process works
- AutomationThe enrolment form goes straight to the robot; nobody retypes anything
- AutomationThe robot checks free places and reserves the group, or proposes another
- AutomationThe contract with data and instalment schedule goes out for e-signature in minutes
- PersonThe office steps in for discounts, transfers and unusual requests
- SystemInstalment reminders and payment ticking from the export run by themselves
- AutomationA morning summary in Teams: enrolments, signatures, arrears
Human-in-the-loop model
Automation handles
- Intake, place reservation, the contract from the template and the instalment schedule
- Reminders before the due date and payment matching from the bank export
- Order in the documents and a morning enrolment summary in Teams
People decide
- Talking to parents and setting the level when the placement test is not enough
- Decisions on discounts, transfers between groups and spreading arrears
- Contact with a student who stays behind despite reminders; the robot collects nothing
Before and after
Systems and integrations
The stack is short on purpose: one engine, one execution layer, one place where a person decides.
Inputs
- the enrolment form from Forms or the website
- the group and student register
- the contract template in Word with fields
- the bank statement as a CSV/MT940 export
Automation layer
- UiPath Orchestrator
- UiPath Robots
- UiPath Integration Service
- UiPath Action Center
Target systems
- signed contracts in group folders in SharePoint
- an instalment register with the status of every payment
- summaries and alerts in Microsoft Teams
Human touchpoints: approving exceptions from the phone; decisions on discounts and transfers; a weekly look at arrears
Technologies used
the enrolment queue, instalment reminders, retries, a trail for every contract
Athe enrolment mailbox, contract folders, the office channel
Asigned contract scans when a student prefers paper
Athe enrolment form and the register of groups, students and instalments
Atext reminders and remote contract signing; on your own provider contracts
BHow we deliver this
From this description to a running process
We deliver this solution through our process automation service: first we measure the process on company data, then we build, test and maintain the robots.
Industry
Case studies
Delivered client work is described under Case studies.
Illustrative economic model
Numbers you can check against your own data.
The model assumes 480 enrolments a year and 25 minutes per document set; it does not count students saved by a fast contract, because we do not honestly know that number. Put your own figures into the calculator beside.
Run the numbers on your data
An illustrative estimate based on your inputs. It models freed capacity, not promised savings.
Business benefits
- The contract reaches the student minutes after enrolment; fewer sign-ups die in transit
- A September and February without overtime and without a third seasonal hire
- Instalments reminded before the due date and ticked off automatically on payment
- One register instead of three notebooks: who signed, who is behind, where the places are
- Fewer annexes, because data is merged from the form rather than retyped
The management view
- Course sales stop depending on whether the office keeps up with paperwork at the peak
- The state of enrolments and money is visible every morning, not when someone finds time for the spreadsheet
- Cash returns closer to instalment due dates, which matters in a school living off two peaks a year
Board-level KPIs
time from form to sent contract · share of enrolments completed with a signature · contracts needing corrections · average instalment payment delay · office overtime at the peak
Security and governance
The automation has exactly the permissions it needs. Not one more.
- Student data, including children’s, is processed only as needed for the contract and billing, in line with GDPR
- The robot has no access to bank accounts; it reads only the statement export you share with it
- Every reminder and every change in the instalment register is logged: what, when, to whom
- The school sets the content and frequency of reminders; the robot takes no debt-collection actions
- Data stays in your Microsoft 365 tenant; the robots run in the EU region of UiPath Automation Cloud
Why now
The next enrolment peak is weeks away, and a deployment of this class fits inside that window.
Parents enrol children from the phone in the evening and compare two or three schools at once; a contract after a week loses to one after fifteen minutes.
An office that stops retyping has time for parents and for keeping groups together, which is what the school lives off.
Relevant executive roles
Sees enrolments and money every morning; September stops being the month she dreads
Talks to parents and builds groups instead of patching contracts in a word processor after hours
Enrolment from the phone in the evening, the contract before bedtime, a reminder three days ahead of each instalment
Common questions and objections
Yes, the robot works on your template. We only turn the data fields into merge fields; the legal wording stays untouched, and a template change is a one-file swap.
The office ticks the payment off with one click in the register, and the robot keeps watching the rest of the schedule exactly as with transfers. Cash does not fall out of the system.
That is a human decision. The office changes the group in the register, and the robot recalculates the instalment schedule and prepares an annex for signature if the price changes.
When this is not the right solution
- A school with a few dozen students a year and contracts signed only on site: a notebook can be enough there
- Enrolments run entirely through an external platform that already handles contracts and payments: we then automate what the platform does not
- A contract template that changes every week: stabilise the template first, automate second
A question for the next management meeting
How many students from last September enrolled elsewhere before our contract reached them?
Implementation approach
Scope without ambiguity, before anything is signed.
We deliver
- An enrolment form connected to the group and free-places register
- A robot generating contracts from your template and sending them for e-signature
- An instalment register with pre-due-date reminders and payment matching from the export
- A morning summary of enrolments and payments in a Teams channel
- An office handbook and two weeks of assistance after go-live
We need from you
- The contract template in Word and the course price list with instalment variants
- Access to Microsoft 365 and a SharePoint home for the register
- An hour with the office to walk through today’s enrolment process
Stages
Discovery
How an enrolment runs today, from the form to the last instalment; half a day with the office
Template and rules
Fields in the contract, the price list, instalment variants, reminder tone
Build
The form, place reservation, contracts, schedules, payment matching
Parallel run
A week: real enrolments through the old and the new way at once
Go-live
New enrolments go through the robot; a review before the season peak
A fast payoff. The biggest work is a one-off tidy-up of the contract template and instalment price list; the technology itself runs on Microsoft 365, which the school usually already has.
Tuesday, 7:40 pm: a mother fills in the enrolment form. The old way, the contract would go out next week. The new way: signed before bedtime stories.
Send us your enrolment count from last September, your contract template and the instalment price list. We will send back the count of office hours to recover and a draft of the form everything starts from.
Count your SeptemberThe neighbouring process usually has the same problem
Attendance in a notebook, meal charges from attendance, parents’ bills by hand. Every month.
See the solution Finance & accountingInvoices chased before they turn difficultThe client pays after 40 days because nobody reminded after 14. The cash sits with others.
See the solution Customer serviceOne inbox instead of four channelsEmail, Messenger, phone and a form. Four places where the customer could ask the same question.
See the solution