What I took from it
A Copilot skill is a small piece of design surface but a useful one to do well. The work sits in the scoping: what context to give the model, what counts as a good output, and where the human stays in charge. Those are design decisions, not engineering ones.
The principle that ports to other domains: AI augments judgment, it doesn't replace it. In customer support, in legal drafting, in any domain where the human is liable for the output, the design job is to compress drafting time while leaving the judgment surface untouched.
Read the full case study
What this is, and what it isn't
This is a Copilot skill, not a custom-built agent. The platform does the heavy lifting; the design work was scoping what the skill should do, loading the right context, defining what 'a good draft' looks like in Bibel TV's tone, and building the workflow around it.
It isn't a custom-trained model, it doesn't have a self-learning feedback loop, and it doesn't auto-send. The team sees the draft, decides, and sends. The skill just compresses the blank-page part of the job.
The Problem
Bibel TV gets a steady stream of letters and emails from viewers, many of them sensitive, about faith, personal questions, or grief. Each reply has to feel pastoral and warm, follow the company's customer-support handbook, and address the specific concern. Drafting from a blank page eats hours per week, and tone consistency drifts depending on who's writing.
The design decisions
Handbook is the context, not the model
The skill loads the CS handbook, its wording, formatting and standard phrases, as context with each draft. The model isn't trained on it; it just reads it alongside the incoming message. Handbook updates take effect the moment the document changes. No retraining, no pipeline.
A fixed shape for a good reply, not a vibe
The system prompt doesn't stop at what to avoid. It specifies a fixed answer structure, a house-voice specification, and the channel links to close with. For emotional messages specifically it calls for high empathy and pastoral language, with scripture or a promise of prayer where it fits. That's a concrete target for what 'good' looks like, not a generic instruction to sound nice.
Human keeps the send decision, always
The draft never goes out without a human edit-and-send. Efficiency was never what was being traded here. This is the design point. For sensitive communications, the human judgment is the product. The skill moves the blank-page problem; nothing more.
The human is upstream, not downstream
The copilot is embedded in nothing. Viewer services works largely from paper post, so a person opens the letter, reads it, decides whether the tool is worth reaching for, enters the content, and edits the draft before anything is sent. The judgement sits ahead of the model rather than behind it, which is the opposite of how most assistive AI is arranged.
The system prompt refuses in one case, and it is a useful one. If the input is not a viewer enquiry at all, an internal team note for instance, it declines to produce a reply and asks for clarification instead. A confident draft answering the wrong thing is worse than no draft.
What changed
Letters that touch several topics at once used to take hours to draft. Now they take minutes. Temporary support staff write in the company's voice from their first week instead of absorbing it slowly over months. And the sceptics on the team, the ones who doubted a drafting tool would hold up on anything real, came around only after they tried it on their hardest letter, not their easiest.
Curious how a copilot that never touches an inbox, no auto-read, no auto-send, still turned the team's sceptics around, each on their hardest letter? Get in touch.