A Kenyan service desk
Build a county-aware English/Kiswahili assistant using your service documents and an optional support action.
Suppose your organisation serves customers in several Kenyan counties. The assistant should explain your services, ask where the customer needs help and submit a request only when an actual tool succeeds.
Prepare your business sources
Upload your service coverage, opening hours and support policy in Knowledge. Include the county names your business serves and any exclusions. Review extraction, amounts and conditions, then approve public disclosure.
Keep changing service details in documents rather than repeating them across long prompts. Use a prompt to define the task and language, and source evidence to define what your organisation offers.
Choose the behaviour you need
| Need | Configuration |
|---|---|
| Checked factual advice from reviewed sources | Validated documents only, Pipeline speech, reviewed/unexpired evidence and tested fallback messages. |
| Enforced name/county/issue intake | Conversational answer behaviour, Pipeline speech and a Flow with required fields. |
These are distinct paths: structured flows cannot currently combine with validated-document mode. Pick the primary requirement rather than assuming a prompt can enable both.
Configure language and intake
Set timezone to Africa/Nairobi. Begin in English or Kiswahili according to your audience and test an explicit switch request. Use the sample prompt as a starting point.
For a flow, collect customer_name, county and issue. Use choices from your own coverage list where appropriate, ask again when a value is unclear, and read back the request before submission. A county mentioned by the caller is customer context, not proof that service is available there.
Add a real support action
If your workspace offers a published API Request or CRM tool, connect your organisation's account and assign that tool. Pass the collected request fields, show or read the action summary, and require approval.
Test approval, decline, server failure and an unknown result. Claim “submitted” only after confirmed success; otherwise offer the configured follow-up path. Without a configured tool, the assistant can collect information but must not claim it created a ticket.
Test and release
Include a supported county, an unsupported county, an ambiguous location, Kiswahili input, missing evidence and a declined action in your evaluation suite.
Publish the chosen configuration, connect a website or WhatsApp channel and repeat the scenarios there. Review evidence, action status and shared usage balances during your pilot.