Treat presets as live starter kits

Quick start, real behavior

A preset saves typing. It does not transfer responsibility.

Contact Information, Business Hours, and Contact Request are editable Tool definitions. Their values are examples or environment-derived defaults—not verified facts about your organization and not a safety review.

Important: presets arrive enabled

Installing a bundled preset creates it with Enabled on. It can become available to its assigned runtime immediately. This is especially important for Contact Request, which targets the site administrator email by default and can send real mail.

The safe sequence is: install one preset, go directly to Your Tools, switch it off, edit every field, test it, then enable intentionally. Do not install all three and plan to review them later.

Open the three starter kits

What is actually installed
Preset	Initial behavior	Values that demand review	First safe test
Contact Information	Static Data Tool named `get_contact_info` with public-contact fields.	Phone, email, address begin blank; contact path is `/contact`. Check the whole returned object and Assistant assignment.	Keep disabled; enter synthetic public values and run the data test.
Business Hours	Static Data with Monday–Friday 09:00–17:00 and Saturday/Sunday Closed.	Every day, time zone, seasonal schedule, holiday exception, appointment-only rule, and which location these hours describe.	Replace samples with a clearly fictional schedule, verify JSON, then ask about one open and one closed day.
Contact Request	Email action sent to the WordPress `admin_email`; subject includes visitor name/topic; name, email, and topic required, message optional.	Recipient inbox, consent wording, privacy expectations, subject/body, Reply-To, Assistant assignment, error language, spam controls, and Basic/Advanced behavior.	Change To to a controlled test inbox, keep disabled from chat, then use one synthetic admin test.

If a Tool with the same Function Name already exists, preset installation will not create a duplicate. Inspect the existing Tool rather than assuming the preset upgraded or replaced it.

Preset teardown: Contact Information

This template is a small public data object, not a live contact-directory connection. Blank values are not magically filled from WordPress. Replace or remove empty fields; do not let the Assistant answer with an empty phone or invent one.

Decide whether Static Data or the Knowledge Base owns contact information. Static Data is good for a compact stable directory. A location page is better when directions, accessibility, service boundaries, holiday closures, and explanatory context matter. Avoid maintaining two conflicting authorities.

The /contact path is only a sample relative path. Confirm that it resolves correctly in the website experience where the chat is used.

Preset teardown: Business Hours

The weekday values are examples, not plugin defaults for your organization. Replace all seven days and add context inside the data where ambiguity exists: location, time zone, appointment-only periods, lunch closures, public-holiday handling, and whether phone hours differ from opening hours.

Test questions such as “Are you open Friday at 16:30?”, “What about Saturday?”, and “Are those phone-support hours?” If the data cannot answer the last question, improve the structure or let the Assistant explain the limitation from approved knowledge.

Preset teardown: Contact Request

This is a side-effecting Email Tool. Its default destination is the WordPress administrator email, which may be a developer, agency, unattended technical mailbox, or personal address. Choose a monitored operational inbox intentionally.

The default parameters are a useful starting contract, but they do not capture your privacy notice, response-time commitment, regional consent requirement, or CRM process. A true wp_mail() result does not prove delivery. In Basic runtime the model can call the enabled Tool without the Advanced visitor-approval gate; in Advanced runtime the email action is protected by approval policy when connected to a specialist.

Test in widening circles

Do not jump from “saved” to public traffic. Each circle answers a different question.

1. InspectIs configuration truthful and narrowly assigned?

2. Admin testDoes the implementation return and create the real expected result?

3. Basic chatDoes natural language call it only when intended?

4. Advanced flowDo specialist scope, confirmation, cancel, and duplicate protection work?

5. Monitored launchDo logs at both ends agree under real usage?

Admin Test is a real execution console

Selecting Test runs the saved implementation. Static Data and WP Option return real values. Email sends to the configured destination. Webhook contacts the configured URL. WordPress Hook invokes the registered callback. Use synthetic values and sandbox destinations.

A test set that earns confidence
Case	Expected evidence	Why it matters
Valid complete input	Tool result and receiver log/state both show one intended operation.	Proves the happy path across the boundary.
Missing required input	Execution stops with an understandable error and no side effect.	Checks schema enforcement and honest prompting.
Invalid email-like input	Email validation rejects it before action.	Prevents obvious malformed reply addresses.
Unexpected/long characters	Receiver safely validates, stores, or rejects without injection or broken output.	Model-facing types are not full business validation.
Ambiguous chat request	Assistant asks or answers without running the action.	Tests routing rather than implementation.
Repeated identical request	Receiver prevents or safely tolerates duplicate side effects.	Networks and people retry.
Remote failure/timeout	Visitor gets a safe accurate error; internal log keeps enough evidence.	Tests the outcome most likely to be ignored in a demo.

A practical release card

Install one preset.
Immediately disable its list toggle.
Replace every blank, sample, default recipient, label, description, and Assistant assignment.
Read the entire returned data shape or action template.
Run one controlled admin test and verify the real receiving system.
Exercise failure and repetition, not only success.
Test from Basic chat, because that runtime lacks the Advanced action-approval gate.
If used in a flow, connect it to one specialist, run the simulator safely, publish, and test approval/cancel.
Enable during a monitored window and keep the disable owner available.

When a test result lies by omission

A green response can only report what that layer knows. Email acceptance is not inbox delivery. Webhook 2xx is not necessarily business acceptance. A Hook’s generic success does not prove a callback performed work. Static JSON returning cleanly does not prove values are current. Always verify the real outcome and define success language accordingly.

Keep the starter from becoming abandoned infrastructure

After launch, assign each installed preset an owner and a review trigger. Contact Information changes when a location, phone, or website path changes. Business Hours needs holiday and seasonal review. Contact Request depends on a monitored inbox, mail delivery, staff process, privacy notice, and response expectations. The Tool list cannot know that any of those business conditions changed.

Review the first real calls in Chat History and at the receiver. Look for questions that call the wrong Tool, values people routinely omit, delivery failures, duplicate submissions, and wording that overpromises. Update one layer at a time and rerun the regression set. If a preset no longer has a clear purpose or owner, disable it; quick installation is not a reason for permanent exposure.

See the preset shelf

Screenshot capture pending /images/screenshots/tools/presets-testing.webp

Tool Presets, Testing, and Enablement

Capture: Show the three preset cards with Contact Information installed and the other two available; no real organization data.
Show: Preset names, summaries, Installed/Install states, warning copy
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

Continue before enabling

Learn exact action semantics in Email, Webhook, and Hook.
Review disclosure risks in Static Data and WP Option.
Complete the Tool security preflight.