A shared inbox full of attachments
The bookings inbox has forty new emails since yesterday. Some are your booking form, filled in properly. Some are the agent's own PDF, with fields in a different order and a date written as day, month, year or month, day, year depending on the country. One is a spreadsheet with six students for a closed group. Two are plain emails that say 'same as last time for her sister'.
The admissions officer opens each one, retypes name, date of birth, nationality, passport number, course, start date, weeks, accommodation, transfer and special requests into the student system, then sends a confirmation and an invoice. When it is busy, the confirmations go out a day or two later, and agents chase.
Why forms never arrive the same way
You cannot make every agent use your form. Large agencies have their own systems that print their own documents, small ones fill in whatever is quickest, and some deal with you in a language that is not English.
- Different layouts for the same information.
- Dates and names written in different conventions.
- Course names that do not match yours exactly.
- Missing fields that someone has to chase.
- Group bookings with many students in one attachment.
Retyping is the only way to get all of that into one shape, which is why it survives even when everyone hates it.
Where retyping hurts
Typing errors in names and dates of birth end up on documents that matter, such as letters, certificates and anything sent to an authority. A wrong start date means a student arrives to no class and no host. Slow confirmations push agents towards schools that answer faster. In peak season, the admissions team spends its day typing instead of answering questions, and questions are where bookings are won.
The booking intake we build
- The bookings inbox, in Microsoft 365 or Google Workspace, is watched for new emails and attachments from agents.
- Each attachment is read, whether it is your form, the agent's PDF, a spreadsheet or a scanned page, and the booking details are extracted. We use a document model, such as OpenAI or Anthropic Claude, for forms that have no fixed layout.
- Details are normalised: dates in one format, names split correctly, nationalities and countries matched to your list, course names mapped to your products.
- The draft is checked against your rules: is the start date a valid start day for that course, is there space in the chosen accommodation, is anything required missing.
- Drafts land in a queue for the admissions officer with the source document side by side, and any field the system was unsure of is highlighted.
- Confirming the draft creates the booking in your student system and prepares the confirmation and invoice.
- If details are missing, a request to the agent is drafted listing exactly what is needed.
| What arrives | What the intake does |
|---|---|
| Your own booking form | Reads fields directly |
| Agent's own PDF | Extracts and maps fields to yours |
| Group spreadsheet | Creates one draft per student, linked as a group |
| Plain email | Extracts what it can, flags the rest |
| Handwritten or scanned form | Extracts with every field marked for checking |
Nothing is booked without a person confirming it, and uncertain fields are always shown rather than filled in quietly.
The admissions desk afterwards
The admissions officer works through a queue of drafts instead of a pile of attachments. Most need only a glance against the source. Missing details go back to agents the same day. Confirmations go out while the agent still has the student in front of them, and passport and date of birth errors mostly stop, because nobody retyped them.
Is your bookings inbox like this?
- Agents send bookings in several different formats.
- Someone retypes every booking into the student system.
- Confirmations wait until the admissions team catches up.
- Names and dates of birth are sometimes wrong on letters or certificates.
- Group bookings arrive as one spreadsheet that takes an afternoon.