Fraser Page/
04 — AI Engineering

The chatbot that replaced the script system

The problem

The client used a legacy student messaging platform to send script-based SMS messages guiding students through their college journey. My investigation showed it had an abysmally low engagement rate. We had just built a student-facing AI chatbot, and we already had an SMS system inside GRACE — so: connect the dots. Replace the underperforming tool with something that doesn't need students manually exported into a second system, that can reference their actual data, that can use the full toolset we'd built for the chatbot, and that feeds results back into the outcomes the client actually measures.

How

That was an open question. The client rep works with these scripts every day and needed guiding into the world of prompts rather than scripts.

The solution

Two new modes in our campaign scheduler. The first, “from AI,” sends messages to students matched by highly configurable targeting filters. The message can be pre-composed or generated per student from a prompt, with the agent free to look up that student's real records. For example: “this message targets students with in-progress college applications. Let's move those toward applied. Look up the student's applications and offer to help them finish, referencing the specific schools, as character limits allow.”

SCRIPTReminder: completeyour application bythe deadline.Same message,every student.PROMPTHi Maria — you're closeto finishing your OhioState application. Wanthelp with the last part?Written per student,from their actual data.

The old system couldn't come close. The agent always carries its system prompt and understands its directive — help students, keep their data current. Where there are talking points we want hit in a particular conversation, we attach a per-conversation prompt that persists across future messages. Script-like control, a fraction of the work.

The second mode I pitched and built, which the client named “automated touch points,” shares the same filters and prompt field but runs on an ongoing basis. Rather than going out at a set date and time, these messages fire whenever a student newly matches the filter condition — something the previous system had no answer for at all.

One detail I liked

There's considerably more here, but a favourite: wrong numbers. We can't risk exposing student information if an adviser entered the wrong number for a student. The fix is a simple validation step. We ask the student to confirm their name and check it against our records. A wrong number isn't going to guess it. Simple, cheap two-factor.

← 03 — Student tasks that create (and complete) themselves01 — Model context is its UI →