Connect learner support to reliable operational knowledge

Start with the operational bottleneck

Learner support mixes stable guidance with rapidly changing operational details. Course access, account settings, payment processes, and programme schedules may be documented in different tools. During a platform migration, even a correct old answer can become unhelpful.

Start with a defined support area, such as course access and account navigation. Create a list of policy owners and known change dates. Separate public information from account-specific records and requests involving money, eligibility, or academic decisions.

Design the target workflow

Retrieve approved help content and, after the existing verification process, the limited account context needed for the request. Generate an answer that points to the current instruction or account state. Route unsupported questions with a summary of what was checked.

For operational changes, use AI to prepare a readiness checklist: affected articles, support macros, likely questions, and unresolved policy gaps. A content owner approves updates before publication. Keep the assistant’s knowledge synchronised with the rollout date so old and new instructions do not blend into a single answer.

Connect to the existing systems

Connection	Information	Control
Help centre	Approved instructions and effective dates	Maintain owners and withdrawal rules
Account tools	Verified access and relevant account state	Retrieve only what the support task needs
Change workflow	Affected content and readiness actions	Approve updates before the change goes live

Use stable identifiers and versioned inputs. A retry should resume the same piece of work, with the original permissions and evidence attached. Treat an upstream outage as a visible workflow state.

Fit the model to the task

Use a small model for question classification, grounded responses, and content-change analysis where it passes tests. Evaluate on the language and terminology learners actually use. Escalate complex or sensitive requests to a person rather than adding unsupported account actions.

Keep a clear human boundary

Check identity before account access. Keep refund, eligibility, and academic judgement outside automatic responses. Test stale policies, ambiguous course names, inaccessible accounts, and conflicting help articles. The support team must be able to withdraw a bad answer source quickly.

Measure the complete operating cost

Measure resolution with a clear denominator, repeat contacts, and handoff quality. Include content maintenance and migration preparation. A resolved share of model-touched conversations is not the same as the share of all support work completed automatically.

Pilot checklist

• Bound the first release to a support area with approved content.
• Separate public guidance from verified account context.
• Test effective dates and platform-migration scenarios.
• Track repeat contacts and human corrections.
• Keep policy changes owned by the support operation.

Agree on acceptance thresholds before testing, then compare the proposed workflow with the same work handled through the current process. Expand only after the operation can explain both successful and failed cases.

Further implementation detail

• Choose the lowest-cost model that meets the task requirements
• Serve a local model to a team
• Ollama’s local API reference