Applications · Deals
University application tracking CRM: every application is its own deal
Students apply to three, five, sometimes more universities at once. Xale is study abroad application management software where the student is one lead and every university application is its own deal — its own stage and status, its own owner for each role, its own follow-ups, payments and team chat — while the documents, calls and WhatsApp history stay on the student record underneath them all.
Updated · By the Xale team
The problem
One row per student stops working at the first offer letter
A spreadsheet with a “University 1” column, or a generic sales CRM that allows one deal per contact, holds up until a student has more than one live application. Then the second and third end up in a notes field, and everything downstream — deadlines, ownership, reporting — inherits the mess.
One status column, three different answers
The student has an unconditional offer from one university, a conditional offer from another and a rejection from a third. Whatever a single status field says, it is wrong for two of them.
Deadlines that belong to one application
The deposit is due on the 15th for one offer, conditions close on the 30th for another. A single “next follow-up” date on the student hides everything except whichever one was typed last.
Counts that flatter or under-report
A student with three offers is counted once and the university data disappears, or counted three times and the conversion rate looks twice as good as it is.
If you are still designing the structure, our guide to tracking multiple university applications sets it out tool by tool, including how to pick the application that represents a student in reports. This page is about how that structure works inside Xale.
The model
One student record, one deal per university application
In the study abroad CRM, the student is a lead and each application is a deal underneath it. Everything that is true about the person stays on the student; everything that is true about one university and course belongs to the application. Here is where each thing lives.
| What | On the student (lead) | On each application (deal) |
|---|---|---|
| The record | One lead: the student and their family | One deal per university and course, named university first, for example “University A - MSc Data Analytics” |
| Stage and status | The student’s own stage, status and sub-status on the pipeline | Each application carries its own stage, status and sub-status, and moves independently of its siblings |
| Owners | One active owner per role on the student, for example a telecaller and the lead counsellor | One active owner per role on each application, so a UK desk and a Canada desk can hold different applications for the same student |
| Follow-ups | One live follow-up per role on the student | One live follow-up per role on each application, with its own due reminder |
| Documents | Folders on the student record, shared by every application, so one passport serves them all | No separate folder: a file uploaded from an application is filed on the student. Name folders by university if a file belongs to one |
| Money | The student’s overall payment history across applications | Payments and EMI instalment plans per application, with Razorpay links and reminders |
| Team chat | An All Chats thread for the whole student | In the web app, a channel per application, copied into All Chats with the application’s name in front |
| Custom fields | Lead Preference: fields shared by every application, plus profile fields such as qualifications and test scores | Deal Preference: values that belong to this application alone, such as destination country and intake, plus its university and course links |
Open a student and their applications sit in a rail at the top of the drawer, grouped under the stage each one is in. Click one and the whole drawer follows it: the stage and status controls, its owners, its follow-ups, its payments, its chat and its activity log all belong to that application until you pick another or go back to the student.
The one deliberate exception is documents. They are stored at student level and shared by every application, which is right for a passport, marksheets or an English test report, and something to plan for when a file belongs to a single university — see student document management.
What it looks like
One student, four applications, four different answers
An illustrative student with four applications, one of them already closed. Each row is one deal with its own position on the pipeline, its own owner and its own next step — and all four hang off a single student record with one set of documents and one call history.
| Application (deal) | Stage · status | Owner | Waiting on |
|---|---|---|---|
| University A - MSc Data Analytics (UK) | Deposit · Deposit requested | UK application officer | Deposit, then the confirmation document |
| University B - MSc Business Analytics (UK) | Application · Offer received (conditional) | UK application officer | English test result to clear the condition |
| College C - PG diploma (Canada) | Application · Application in progress | Canada counsellor | University decision |
| University D - Master of IT (Australia) | Application · Rejected | Australia counsellor | Closed with a rejection status, kept for next season |
Illustrative example with placeholder university names. Xale sets no limit on how many applications a student holds, and no plan caps them; the one thing it refuses is a duplicate — the same course and intake again while an earlier application is still live. The rejected one above is closed with a rejection status rather than deleted, which is how rejection data by university builds up for next season.
Application pipeline
Each application moves on its own clock
Moving one application does not drag the others with it. Everything that governs a move — the pipeline, stage requirements and status-to-status deadlines — applies to an application in its own right.
Started from the course, named by it
A counsellor opens the student’s Course tab, picks the course and presses Start Application. Xale creates the application at the first application stage and names it university first, adding an ordinal when the student already holds others.
Its own place on the pipeline
A new Study Abroad workspace starts with Inquiry, Qualify, Application, Deposit, Visa and Enrolled, with offer statuses (conditional and unconditional), deposit statuses and document sub-statuses inside them. Every application sits somewhere on that pipeline in its own right, and you can rename or extend any of it.
Requirements that hold an application back
Stage requirements are checked when an application moves, not only when the student does. Require named documents, fields, an attached course or university, an assigned role or user, or a track, and the move stops with your message until they are met.
Deadlines between two statuses
Set a deadline from, say, offer received (conditional) to deposit submitted, with early-warning days. It closes itself when the application reaches the target status, so counsellors chase only what is genuinely late.
Rolling one back, carefully
A Previous button walks an application back a stage for whoever has rollback permission on it, with a warning when the student’s other applications sit further ahead. Nothing is erased: the stage history stays on the activity log.
A history that is never rewritten
Xale records the first time an application reached each stage, so an application rolled back later still shows the offer it once had. Open an application and its own activity log shows every stage, status and sub-status change with who made it and when.
A document requirement can also be an info-only checklist item that never blocks a move, which suits documents some universities waive. There is no “warn but allow” middle mode: a requirement either blocks or informs. Requirements are enforced on application moves, student moves, bulk stage updates and stage-change automations alike, and in a bulk update each blocked record is listed with its reason. One requirement is about applications themselves: a stage can ask that the student holds at least a set number of them, which is one way to keep shortlisting honest. The full set of requirement types is on the documents page.
Ownership and hand-offs
Who owns which application, and who is due to act
Country desks, an application team and a visa team can hold the same student at once without stepping on each other, because assignment and follow-ups both work at the application grain.
One owner per role, per application
Assign someone in a role that is not yet on the student and Xale asks whether they join the whole student or one application. The database then allows a single active holder of that role on that record, and past holders are revoked rather than deleted, so the ownership history survives every hand-over.
Follow-ups sit where the assignment sits
A role assigned on the student keeps its follow-up on the student; a role assigned on an application keeps its follow-up there. The UK officer’s date and the visa officer’s date never overwrite each other.
Hand-offs by application
An automation on “Deal sub-status changed” can auto-distribute an application to the next role — one owner per application, or one owner for all of a student’s applications — and send an approved WhatsApp template at the same time.
A chat channel per application
Discussion about the Canada file stays in the Canada application’s channel, and every message is copied into the student’s All Chats so the whole story stays readable. Access follows the lead and the application.
How the roles, reminders and team hand-offs work in full is on follow-up management, and the per-application channels on internal team chat. Who can see which students, branches and destinations is set by roles and branches: multi-branch access.
Working the list
Finding the applications that need you today
Filter students by where an application sits
Filter by a stage, status or sub-status and Xale also returns students whose application is there, even when the student’s own row sits elsewhere. The card is labelled with the matching application’s stage.
Filters that count applications
A Deal Info section filters on whether a student has any applications, how many sit in a chosen stage and status, and when applications were created or last updated. Payment filters add deal value, pending amount, instalment plans and overdue instalments.
List, grid or board
The same filtered students switch between a table, cards and a board with one column per status. A card with several applications carries a badge with the count and flips through one slide per application, each showing its own stage and status.
Columns for the teams behind each application
The list’s role columns separate the people on the student from the people assigned at application level, such as application and visa teams, so a table of students still tells you who holds what.
Save any set of filters as a favourite view with its own place in the sidebar — “Offers awaiting a deposit, my branch”, say — private or shared with chosen roles. The Xale Android app carries the same students and applications, with follow-ups on the same India calendar days and the same permissions as the web. More on lists, views and bulk actions in lead management software.
Fees and deposits
Money that belongs to one application
A deposit is paid to one university, not to a student in general. Payments follow the application, so the outstanding balance on the UK file is never confused with the Canada one.
Fees per application
Each application carries its own fee, discount, amount paid and pending balance. Record payments against the application they belong to, or split its fee into an EMI instalment plan that reminds the application’s owners before the due date, on the day, and daily once overdue.
Razorpay links that record themselves
Send a payment link by WhatsApp from a connected Cloud API number, by email from your connected Gmail, or as a copied link. A paid link is recorded on the application automatically through a signature-verified webhook.
Three money views, never added up
Cash collected in a period, receivables as of today with ageing, and deal economics by the month applications were created. Xale keeps them apart instead of summing one into another.
The Payments tab ships with the Study Abroad and Video Production templates, and with Academy once an admin adds a deal stage. Amounts are in rupees, and payment links run through Razorpay. Plans are on the pricing page.
Reporting
Counting many applications without double counting students
The question behind most bad admissions reports is “am I counting students or applications?”. Xale answers it per metric and keeps the answer the same everywhere the metric appears.
A student counts once in conversions
However many applications a student holds, conversions count distinct students. The Admissions tab keeps the application grain, following offer, deposit, visa and enrolment application by application.
Anchor points count what got there or further
Mark a milestone stage such as Deposit as an anchor point and it counts every student with an application that reached that stage or any later one, so the number does not fall as students move on.
First to reach it, inside the window
With “New this period” on, a date range counts students whose first application to reach the milestone got there in range. A second application crossing later does not count the student again.
Every number opens its list
Click a count and Xale opens the exact students behind it, carrying the card’s date rule, role scope and application grain, so the report and the list agree.
Stage-level figures are counted the same way in the report and in the list they open, including the first pipeline stage, which is counted by the date leads arrived rather than by stage moves. The tabs, the drill-down rule and the admissions funnel are covered in CRM reports and analytics, and platform, reliability and onboarding covers how a workspace is set up and supported.
Limits
What Xale’s application tracking does not do
Worth knowing before you choose, and easier to read here than to discover in month two.
- No connection to university portals, UCAS, Common App or SEVIS. Nothing is submitted from Xale and no decision is imported: a counsellor records the outcome by moving the application and uploading the letter.
- No pre-loaded university or course library. You import your own universities and courses in bulk from Excel, and the Course Finder searches the list you actually work with.
- Documents are stored at student level and shared by every application, which suits a passport or marksheets. For a tailored SOP or one university’s offer letter, name the folder after the university.
- One generic Visa stage rather than a workflow per destination, because country rules change too often for a fixed template. Country-gated statuses and stage requirements are how you model each destination.
- No student or sub-agent portal and no applicant-facing application forms. Xale is counsellor-facing: students reach you by WhatsApp, calls and forms.
- Requirements are blocking or, for documents, info-only checklist items. There is no “warn but allow” mode, and they are checked on stage and status moves, not on import.
- No separate list of applications across students: every list, board and export is a list of students. You reach applications through the student, the Deal Info filters, grid cards and the admissions reports.
- Deleting an application is permanent. Leads go to Trash and can be restored; a deleted application cannot, so close rejected applications with a rejection status instead.
- The Admissions and By Stage report tabs cannot be exported yet, and report output is CSV or XLSX, never PDF.
- The Custom Report Builder is coming soon, so application reporting is what the eleven built-in tabs and saved views cover.
- Amounts are in rupees, with no multi-currency or exchange rates, and report dates follow India calendar days.
Comparing tools? Eight study abroad CRMs compared explains our method and says where another tool is the better choice.
Frequently asked questions
University application tracking: common questions
What is a university application tracking CRM?
A CRM that keeps one record for the student and a separate record for each university application, so an application can have its own stage, owner, deadlines and documents without the student record losing the thread. In Xale the student is a lead and each application is a deal under it, which is what makes three offers, one rejection and two pending decisions describable at the same time.
Can one student hold several university applications in Xale?
Yes. Each university and course combination is its own deal under one student record, with its own stage, status and sub-status, its own owners per role, its own follow-ups, payments and team chat channel. The student’s documents, calls and WhatsApp history stay on the student record and are shared by every application.
Can two counsellors own different applications for the same student?
Yes. Ownership is per role and per record, and the database allows one active holder of a role on each application. A UK desk can own the UK applications while a Canada desk owns the Canada one, each with their own follow-up and reminder, while the lead counsellor keeps the relationship on the student record.
Does each application keep its own document folder?
No. Documents are stored on the student record and shared by every application, so one passport or transcript serves them all. Upload from an application and the file still lands on the student. For files that belong to a single university, such as a tailored SOP or that university’s offer letter, name the folder after the university.
Does Xale submit applications to universities or import their decisions?
No. Xale does not connect to university portals, UCAS, Common App or SEVIS, does not submit applications and does not sync decisions or application status from a university. Your team submits in the university’s own portal and records the result in Xale by moving the application and uploading the letter.
Can a move be blocked until an application is complete?
Yes. Stage requirements are enforced on application moves as well as student moves: require named documents, fields or custom fields, an attached course or university, an assigned role or user, or a track, and the move stops with your message until they are met. Document requirements can instead be info-only checklist items that never block a move.
How do reports count a student with three applications?
Conversions count distinct students, so three applications add one conversion. The Admissions tab keeps the application grain and follows each one through offer, deposit, visa and enrolment, and anchor points count every student with an application that reached a milestone stage or a later one. Click any number and the list it opens uses the same rule.
Is there a university and course database built in?
No. There is no pre-loaded library. You import your own universities and courses in bulk from Excel or add them by hand, then counsellors use the Course Finder to filter by country and other facets, compare courses and shortlist. An application links to the university and course from your own list.
Related guides
- Study abroad CRM softwareThe whole product: pipeline, capture, calls, WhatsApp and reports.
- Guide: track multiple university applicationsThe vendor-neutral method, including which application represents the student.
- Student document management softwareOne file vault per student, and stage requirements that hold a move.
- Follow-up management CRMOne follow-up per role on every student and every application.
- CRM reports and analyticsAdmissions deal by deal, anchor points, and numbers that open their list.
- CRM with internal team chatA thread on every student and a channel on every application.
- Multi-branch CRM with role-based accessWho sees which students, branches and destinations.
- Best study abroad CRM: eight tools comparedOur method, the trade-offs and when another tool fits better.
Give every application its own record.
One student, as many applications as they hold, each with its own stage, owner, deadline and deposit — and one honest number at the end of the month.