Working with AI Enablement
For chatbots that need to reach the public, handle real volume, or live on your website.
How it runs
Intake → Scoping → Content readiness → Build → Test → Launch → Operate
Content readiness is the usual bottleneck and how long it takes is almost entirely up to you. Everything else runs to a fairly predictable schedule.
Who does what
We build and advise. Your unit owns the content, the accuracy, the cost, and the chatbot’s life after launch.
| Activity | Your unit | AI Enablement |
|---|---|---|
| Define what it covers | Decides | Advises |
| Prepare the content | Does it | Advises |
| Build and configure | Collaborative | Collaborative |
| Judge whether answers are right | Does it | Facilitates |
| Deploy it | — | Does it |
| Tell people it exists | Does it | — |
| Keep content current | Does it | — |
| Watch for problems | Does it | Available to consult |
| Platform and model updates | — | Does it |
| Decide to retire it | Decides | Advises* |
* AI Enablement reserves the ability to disable or retire any chatbot that violates the responsibile use policy.
Roles you’ll need to fill: sponsor, content owner, day-to-day contact, testers, budget owner, technical contact. One person can hold several. None can be empty. The Roles & Ownership template is where you write this down.
What we provide
- Advice at any stage
- Architecture, build, and configuration
- Help with evaluation and testing
- Deployment and documentation
- Availability for consultation after launch
What we don’t
- Write your content
- Judge whether your subject matter is correct
- Maintain it
- Answer your users
- Monitor it
- Fund usage costs
Data
Use your unit’s own content freely. For data another unit owns, or anything restricted — student records, health, financial, or personnel information — that data’s steward approves the use.
We’ll help you work out who that is and prepare the request.
Start those conversations during scoping. They’re usually straightforward and never instant. Discovering one at the launch checklist is the most avoidable delay in this whole process.
What it costs
The University funds the platform and our time. Your unit pays for the AI usage.
You set a budget cap — monthly, total, or both. The spend is bounded. This is not an open-ended commitment.
Usage is charged back to a FOAPAL you provide, and you’ll get notifications as you use up your allotment.
Two things follow from that:
- Set the cap against your busiest month, not an average one. Registration, deadlines, orientation. A chatbot that goes dark during your peak week costs you more than a slightly higher cap would.
- Name someone who’ll actually read the notifications and can act on them. A warning sent to a person on leave is the same as no warning.
What drives the cost: how many conversations happen, how much content gets pulled in to answer each one, and how long the answers are. A chatbot nobody uses costs almost nothing.
Narrower scope costs less and answers better. These pull in the same direction, which is unusual and worth taking advantage of.
We’ll estimate during scoping from your expected volume — estimate honestly, since an optimistic number produces a comfortable estimate and an uncomfortable invoice. A pilot gives you real figures before you commit.
Name a budget owner and FOAPAL before launch. If funding ends, the chatbot is retired. Ask us for current figures — they change.
The platform
We currently build on Onyx. In practice this doesn’t change much about what you do — your work is the content, the questions, and the testing, and that’s the same regardless of what we build on.
After launch
We’re available for consultation whenever you need us. Day-to-day operation, monitoring, content updates, and answering your users belong to your unit.
Ready to talk?
Bring your audience, some real questions people ask, where your content lives, and who your sponsor and content owner would be.