Written, 14 July 2026

The ownership question everyone postpones

An assistant on a company website is unusual in that three departments each have a legitimate claim on what it says, and it can only say one thing. In most organisations this is never resolved, because nothing forces the question until an answer goes out that one of the three would never have approved. Then it is resolved at speed, badly, usually by whoever is angriest.

One voice, three sets of expectations

Support judges it on accuracy and on whether it reduces load. A good day is one where nobody had to correct it and the queue was shorter.

Marketing judges it on whether it helps people buy. It sits on the website, in the funnel, in a spot that used to be a call to action, and from that vantage point an assistant that answers thoroughly and then stops looks like a missed conversion.

Legal, or whoever handles risk in a smaller company, judges it on exposure. Every sentence it emits is published in the company's name, which means it can create expectations, misstate terms, or say something regulated.

None of these is wrong. They are simply different objectives applied to one output stream, and unlike a website, where each department owns different pages, there is nothing here to divide up.

What actually happens without an owner

The pattern is consistent. Support sets it up, because support felt the pain. It runs well for a while. Then marketing asks for a change: mention the trial, suggest the upgrade, capture more emails. The change is reasonable and gets made informally, often by editing the instructions.

Then something goes wrong. Usually the assistant makes a commitment it should not have, or answers a question that should have gone to a person, or says something that reads as advice. This gets escalated, and legal arrives with a set of constraints written after the incident rather than before it.

The end state is a system with layers of accumulated instructions from three departments, none of which know what the others added, and behaviour that nobody can predict or explain. At that point the usual outcome is that it gets quietly turned off, which is a waste of the work that went into it.

One owner, named decision rights

The model that works is single ownership with explicit decision rights for the others. One named person, almost always in support, owns the assistant: the material it reads, the settings, the review cadence, and the record of what changed and when.

That person is not a monarch. They own the artefact and the process. The other parties own specific decisions, and those decisions are written down in advance rather than negotiated after each incident.

The key rule is that all three parties change the same thing: the material. Marketing does not get a separate instruction channel and neither does legal. Requests become changes to indexed documents, which are visible, reviewable, and testable, rather than invisible modifications to behaviour.

Who decides what

Support decides what the assistant is for, what its scope is, which material is indexed, how cautious it is, and what the refusal says. They also own the reading of conversations, which is the feedback loop everything else depends on.

Marketing decides tone, name, appearance, and what the assistant offers to do next when it has finished answering. Whether it points at a demo, a signup, a contact form or nothing is a marketing decision and a legitimate one. What marketing does not get is the ability to make it answer questions the material does not support, because that is a request for it to make things up.

Legal gets a veto rather than a design role, and the veto is over topics and claims: this it must never discuss, this phrasing may not be used, this commitment may not be made. Vetoes are cheap to implement, easy to audit, and do not require legal to be involved in day to day operation. They should be written as a list, dated, and reviewed rather than delivered verbally after an incident.

The escalation route needs an owner too

The part that most often has no owner is what happens after a handover. The assistant takes a name and a message, and the message goes somewhere. Whose inbox, checked how often, answered within what time.

This is worth deciding before launch because it is the one failure that damages you more than a wrong answer. A visitor who was told somebody would get back to them and then heard nothing has been actively let down, and they were let down by a process rather than by a model.

Name the mailbox, name the person, and set a response commitment you can actually meet. If nobody will own it, it is better to route people to a phone number and not offer to take messages at all.

Write it down, on one page

The whole arrangement should fit on a single page. Who owns it. What each other party decides. The list of topics that are off limits. Where the material lives and who owns each document. Who reads the conversations and how often. Where handovers go and who answers them.

The value of writing it down is not bureaucratic. It is that the first incident becomes a process question with a known answer rather than an argument between departments about something none of them thought they were responsible for.

Review it when the assistant's scope changes, and otherwise leave it alone. This is a page that should be boring.

If you take one thing away

The one thing
Name one owner in support, write down what marketing and legal each get to decide, and require that every request from either becomes a change to the indexed material rather than a hidden instruction.

Everything above is the reasoning. This is the part that changes what you do on Monday.

Questions

We are five people. Is this overkill?
The document shrinks but the decisions do not disappear. Even in a very small company somebody needs to own the material and somebody needs to answer the messages the handover produces. Half a page is enough, and writing it takes fifteen minutes.
What if marketing wants it to push a signup on every answer?
That is a legitimate decision within their remit, and it is testable. Try it, read the conversations, and look at whether questions get abandoned mid thread. A closing offer after a complete answer is usually fine; an offer instead of an answer is what damages the channel.
Should the owner be technical?
No. The work is content and judgement, not configuration. The person who reads support conversations all day is far better placed to own it than anyone chosen for their ability to operate the settings screen.

Keep reading

Try it on your own material

Upload a document or point it at your site, paste one line of HTML, then ask it something only your business could answer.