ChatGPT
Claude
Perplexity
Gemini
GrokA custom GPT can answer admissions questions, but it is not an admissions system
A custom GPT is a good prototype and a poor foundation for a UK admissions service. It answers in natural language from the documents you give it, which is enough to test whether applicants would use an assistant. It does not, on its own, give you consent records, a conversation log you control, a clean CRM handoff or a guarantee that it quotes the current entry requirement.
This guide is for admissions, marketing and digital leads at UK universities and colleges who are asking whether a team member can build the assistant in an afternoon. It sits alongside our wider guide to AI chatbots for student recruitment.
What a custom GPT actually is
A custom GPT is a configured version of ChatGPT: instructions, reference documents and optional connections to other systems. OpenAI's developer documentation describes it plainly. A custom GPT combines instructions, attached knowledge documents and actions that call third-party services through APIs, so a link to your CRM needs an API that you build and host.
That last point matters for admissions. The assistant can talk, but writing an enquiry into your CRM is a separate engineering task with its own authentication, error handling and monitoring. Someone has to own that code after the person who built the prototype moves on.
Where it helps, and where it stops
The honest picture is a mix. The table below separates the jobs a custom GPT handles reasonably from those that need more.
| Admissions job | Custom GPT alone | What is missing |
|---|---|---|
| Answering common questions from your own pages | Reasonable for a pilot | A process to keep the source documents current |
| Quoting entry requirements and UCAS tariff points | Risky | Verified, dated source and a refusal rule when unsure |
| Clearing and Adjustment guidance | Risky | Daily data on vacancies; wrong answers cost applications |
| Capturing an enquiry with consent | Not built in | Consent wording, storage and a record of when it was given |
| Passing the enquiry to your CRM | Needs custom API work | An endpoint, authentication and failure alerts |
| Booking an open day or call | Needs custom API work | Calendar integration and confirmation messages |
| Handing a worried applicant to a person | Weak | Escalation rules, staff notification and context transfer |
| Running on your own website | Depends on how it is shared | Embedding, branding and your own analytics |
None of this means a custom GPT is useless. It means the parts that carry risk and value sit around the model, not inside it.
Accuracy: the problem that grows with the calendar
Admissions answers change. Entry requirements move, fees are updated, Clearing vacancies open and close within days, and an applicant who is told a course is still open when it is not will remember it. A language model will answer fluently whether or not its documents are current.
The fix is not a cleverer prompt. It is retrieval from sources you control, a visible date on every factual answer, a rule to decline when the evidence is thin and a route to a person. We cover the technical safeguards in chatbot hallucinations in higher education.
Treat every assistant answer as published information from your institution. Check the conditions that the Office for Students sets for your registration category, and ask your compliance lead how they apply to automated answers.
Data protection under UK GDPR
An applicant who types a question may reveal a disability, a health condition, a visa problem or family circumstances. Under UK GDPR that is personal data, and some of it is special category data, so you need a lawful basis, a privacy notice that mentions the assistant and a clear decision about who the processor is.
The Information Commissioner's Office publishes guidance on AI and data protection, including fairness, transparency and accountability. Complete a data protection impact assessment before launch, and involve your data protection officer early.
There is also a vendor-terms question. According to OpenAI's API data documentation, data sent to the OpenAI API is not used to train or improve OpenAI models unless you explicitly opt in, and this describes the API only, not ChatGPT apps. The terms for a custom GPT used inside ChatGPT are separate, so check the terms of the exact plan and sharing setup before any applicant data touches it. By default the same page says abuse-monitoring logs are retained for up to 30 days, unless longer retention is required by law, which your DPIA should reflect.
Logs, audit and complaints
If an applicant says the assistant told them something wrong, you need to see what it said, when, and on which source. A chat window that a staff member configured gives you little of that history in a form you can search and export.
Decide up front how long you keep transcripts, who can read them, how a deletion request is handled and how complaints about the assistant's answers feed into your normal complaints procedure. Those decisions belong in the design, not in a later fix.
Three routes beyond the prototype
Most institutions end up choosing between three routes, and some combine them.
Build on the API with retrieval. Your developers call the model directly, ground it on your documents and own the front end, the log and the CRM connection. It gives control, and it also gives you maintenance, security review and on-call duty. OpenAI announced the removal of the Assistants API on 26 August 2026 and names the Responses API as its replacement, so new builds should target the Responses API. It is a reminder that a bespoke build inherits every platform change.
Buy a dedicated admissions agent. A specialist product ships with consent capture, escalation, a CRM connector and reporting. You give up some design freedom and gain speed and a team that maintains the product. Skolbot is one such option: a website chatbot that answers prospect questions, qualifies enquiries, books open days or appointments and passes the lead to the CRM, with a WhatsApp add-on.
Combine them. Some teams keep a custom GPT for internal use, such as drafting replies for advisers to check, and use a dedicated agent on the public site. That split keeps the riskiest surface, the one speaking to applicants, under the strictest controls.
| Question | Custom GPT | API build | Dedicated agent |
|---|---|---|---|
| Time to a first pilot | Short | Medium | Short to medium |
| Control of logs and data flow | Limited | High | Contract-defined |
| CRM and booking integration | You build it | You build it | Usually included |
| Ongoing maintenance | Staff time | Your developers | Vendor |
| Best fit | Internal drafting, tests | Teams with engineering capacity | Public admissions service |
This is a planning framework, not a measured comparison. For a wider evaluation grid, see how to choose an AI agent for student recruitment, and for the build-versus-buy detail, SaaS, custom or open source.
A practical decision path
- Pilot with a custom GPT on a narrow set of public pages, internal users only, and write down every wrong answer.
- List the jobs the pilot could not do, using the first table above.
- Decide whether you have engineering capacity to own an API build, including security review and monitoring.
- If not, shortlist dedicated products and ask each to show consent capture, escalation and log export.
- Run a DPIA on the shortlisted route before any applicant uses it.
An illustrative workflow, not a measured result: an applicant asks about a Clearing place at 9pm, the assistant answers from a dated vacancy page, offers a callback and writes the request, with consent, to the CRM for the next morning.
