Prepared answers
Agree common questions, response text and cases that need a person.
AI assistants
AI answers. Your team takes over.
An assistant explains your services, collects the request and passes complex questions to your team.
Discuss this task
- Answers stay on topic
- A clear next step
- Complex cases reach a person
Choose your task
A common question gets a short answer and next step.
- Receive question
- Find response
- Pass to team
When a person takes over: Pass individual requests to the team
The helper shows a short instruction and its source.
- Ask a question
- Find guidance
- Check the path
When a person takes over: If the path changed, ask its owner to confirm
The answer shows its limits and a human next step.
- Receive question
- Check status
- Involve a person
When a person takes over: Do not claim readiness without a confirmed status
Start with what you need
Team assistant
Define internal requests, permitted sources and answer boundaries.
Custom scenario
Design the interaction and assess integrations before stating capabilities.
Where would an assistant help your team?
Finding an answer, preparing a reply and changing a record are different jobs. Choose the help you need before deciding how much the assistant may do. A prepared FAQ, a template or an existing tool may already be enough. If the assistant answers from documents, the search and the assistant can belong to the same project; you do not automatically need two separate setups.
Answer questions on an agreed topic
A first version can cover one topic, one audience and one channel, using information approved for those readers. It should provide supported answers, ask useful questions and make missing or conflicting information clear.
In this mode, the assistant answers questions without managing anyone’s account. General information about a service does not give the assistant access to a person’s order. It does not send messages on their behalf, book appointments or change records in this mode.
Prepare a draft for a person
For repeated replies or requests, the assistant can prepare text for someone to check, edit or reject. The draft makes clear which information is missing. A first project covers one kind of draft and the way your team reviews it, rather than an entire support inbox.
The draft stays in the agreed place for review. Sending it, publishing it or saving it into a mail or CRM account would be a separate action. The work also needs to define who can see the text, where it is processed and how long it is kept.
Complete a selected step after approval
If the result needs to reach another system, the project can include that path—for example, creating one internal request. An authorized person reviews the final details before the action goes ahead. Changes to the details need a new approval, and the required access must still be valid.
We choose whether a person completes the step in their existing tool or the work includes a connection that does it. Those are different deliverables. Either way, the result must be checked in the right place; a written plan is not a working integration.
An unclear outcome pauses further action for review. This first scope does not include payments, refunds, changes to access, deletion, bulk actions or publishing. A general instruction to “handle everything” does not add those functions.
Keep a real person in the right place
Someone on your team needs to check content, decide exceptions and maintain the relevant rules. That person needs the time and permission to do it. Review is part of the process, not a task assumed to take no effort.
A message saying that human help is needed is not proof that anyone received a request. If an actual handoff is needed, we define the recipient, the information they may receive and how to confirm delivery.
What the first project needs
Start with the question, draft or action that would be useful and who can check the result. We then define the sources, readers, channel and limits. Testing needs both useful normal results and cases where the assistant should ask, stop or decline.
An illustrative scenario explains a possible use; it does not establish that the function was delivered or tested. A particular demonstration only supports what was actually checked.
You can describe the task in writing without sending passwords or customer records. Before work starts, we need to agree the cost, timing and who looks after the result.
Before we start
Is the site helper connected to AI?
Yes, but only after you allow AI in the privacy settings: questions are then sent to OpenRouter and the model provider. Without that permission the helper shows prepared answers.
How can invented answers be avoided?
Limit answers to approved material and route unsupported questions to a person.
Can an assistant take actions?
Only after the action, integration, permissions and review have been agreed and implemented.
Who will be able to see our information?
That needs to be defined for the project: who can read or change each type of information, where it is processed, and what is kept and for how long. Signing in does not give someone access to every record, and permission to read a document does not automatically allow it to be sent to another service. A new tool’s access rules need checking, not assuming.
How will we check the work?
We agree what the solution needs to do, then check the actual version against that. You should be able to see what was tested, what worked and what still needs attention. Accepting the work and putting it live are separate decisions.
Who looks after it once the work is handed over?
That should be settled before work starts: someone needs to own content updates, access and the response to problems. Handover, regular maintenance, incident support and new features are different responsibilities. Any support period, response time and cost need to be written down; ongoing support is not automatically part of the initial build.