Write the Assistant’s operating brief
Tell visitors what to expect. Tell the model how to operate.
The Welcome Message and Instructions sit beside each other in the profile, but they do different work. One is public conversation copy. The other is a private brief applied to generated responses.
Welcome Message and Instructions have different jobs
Section titled “Welcome Message and Instructions have different jobs”The Welcome Message is the first message visitors see. It should identify the experience, state a useful scope, and invite a question. It does not force later model behavior and should not contain a long policy.
System Instructions guide every response. SmartSite combines its built-in runtime guidance with the selected profile’s instructions. In Advanced mode, that selected profile becomes the Base Assistant brief while specialist Agents add their own scopes.
| Sentence | Best home | Reason |
|---|---|---|
| “Hello! I can help with our services and public policies.” | Welcome Message | It sets the visitor’s opening expectation. |
| “Use synchronized knowledge for company-specific facts.” | Instructions | It directs response behavior after a question. |
| “Returns are accepted for 14 days under these conditions…” | Knowledge source | The policy needs an authoritative maintainable source, not repeated instruction text. |
| “Submit the callback only after explicit visitor intent.” | Instructions plus Tool/receiver controls | Instructions improve routing; technical validation and Advanced approval protect the action. |
| “Only logged-in customers may use this.” | Settings access and receiver authorization | A sentence cannot authenticate the visitor. |
Write Instructions as an operating brief
Section titled “Write Instructions as an operating brief”A useful brief answers seven questions in this order:
- Role: Who is the Assistant and which organization/site does it represent?
- Audience and scope: Which visitor needs should it handle?
- Sources: Where should company-specific facts come from?
- Uncertainty: What should it do when approved information is missing or conflicting?
- Conversation: How concise, warm, structured, and language-aware should it be?
- Capabilities: When may it use a Tool, and what must never be inferred as permission?
- Escalation: Which approved human route should be offered, without pretending a transfer occurred?
Write direct positive instructions. “Ask one clarifying question when the visitor’s intent affects the answer” is easier to observe than “be smart.” Add high-risk negatives where necessary: do not invent prices, eligibility, availability, account status, or legal conclusions.
Boundaries that remain honest under pressure
Section titled “Boundaries that remain honest under pressure”Avoid telling the Assistant to “always answer,” “never say you do not know,” or “convince the customer.” Those rules reward invention. Prefer: “If synchronized sources do not establish the answer, explain the limitation and offer the approved next step.”
Instructions are not hidden from every risk simply because visitors do not see the field. Do not place credentials, private operating procedures, personal data, unpublished prices, or security exceptions there. They are sent to the model as part of runtime guidance.
A before-and-after example
Section titled “A before-and-after example”Weak:
You are helpful and professional. Answer all questions. Use tools when needed.
This has no organization, scope, source priority, uncertainty behavior, or action boundary.
Stronger:
You are Acme’s public website assistant. Help visitors understand services, locations, and published policies. Use synchronized knowledge for Acme-specific facts. If the sources do not establish an answer, say so and link the visitor to the Contact page. Never invent price, availability, eligibility, or account status. Use the callback Tool only after the visitor explicitly asks to be contacted and provides the required details. Keep answers concise and reply in the visitor’s language.
This still needs technical Tool protection, but it creates behavior that a nontechnical reviewer can test.
Translation is a reviewed replacement
Section titled “Translation is a reviewed replacement”The Translate with AI control is an authoring aid. It sends the source field to OpenAI using the plugin’s translation implementation (gpt-4.1-mini, low temperature, store=false), with source text limited to 25,000 characters and optional guidance limited to 240. Supported choices are English, Dutch, German, Spanish, French, Croatian, Italian, or the plugin default language.
Select Translate, review the read-only proposal, and choose Apply only if meaning, terminology, prohibitions, and escalation remain intact. Apply replaces the form field; it does not save the Assistant. Select Save Changes afterward.
If the source changes after a translation is generated, the review is stale. Generate again. A fluent reviewer should approve legal, safety, brand, and policy language; grammatical polish is not meaning preservation.
Translate without losing the control words
Section titled “Translate without losing the control words”| Instruction element | Translation risk | Review question |
|---|---|---|
| Must / must not | Obligation can become preference. | Is the strength identical? |
| Only after explicit request | Timing/consent may become vague. | Does action remain blocked before clear intent? |
| Approved/synchronized source | Source priority can be generalized. | Does the translated profile still distinguish site facts from general knowledge? |
| Account-specific / public | Audience boundary can be lost. | Will private cases still move to the approved human route? |
| Brand/product/legal terms | Names may be translated incorrectly. | Did all protected terminology remain exact? |
Optional Guidance is useful for “Keep product plan names in English” or “Use formal Croatian.” It is not a place to introduce new operating rules that do not exist in the source instructions.
Edit, save, and test as one change
Section titled “Edit, save, and test as one change”- Copy the current Instructions to the approved change record if rollback matters.
- Change one behavior goal at a time and read the complete brief for contradictions.
- Translate only after the source-language brief is approved.
- Review and Apply the proposal; then reread the final form field.
- Select Save Changes. The edit applies to future runtime requests immediately.
- Start a new/private conversation to avoid old context.
- Run direct, ambiguous, missing-knowledge, out-of-scope, and Tool-intent cases.
- Compare Chat History and retain only a change that improves the target without damaging neighboring cases.
Know when the instruction is not the problem
Section titled “Know when the instruction is not the problem”If the right policy was never retrieved, fix source and metadata rather than repeating the policy in Instructions. If the wrong Tool runs, narrow its own Description, assignment, parameters, and receiver controls. If a specialist owns the conversation, inspect its Agent instructions and routing. If the widget title rather than Assistant greeting is wrong, open Settings → Chat Content.
Review before Apply
Section titled “Review before Apply”- Capture
- Open the Review translation modal over a fictional assistant edit form, showing translated text but no organization-specific policy.
- Show
- Translation language, guidance, review text, Cancel and Apply buttons
- Viewport
- Desktop, 1440 × 900
- Annotate
- Use numbered callouts only for controls referenced in the procedure.
- Redact
- OpenAI keys, tokens, secrets, personal information, private URLs, IP addresses, and conversation text