Skip to main content
SwiftCase
PlatformSwitchboardFeaturesSolutionsCase StudiesFree ToolsPricingAbout
Book a Demo
SwiftCase

Workflow automation for UK service businesses. Created in the UK.

A Livepoint Solution

Platform

  • Platform Overview
  • Workflow Engine
  • Case Management
  • CRM
  • Document Generation
  • Data Model
  • Integrations
  • Analytics

Switchboard

  • Switchboard Overview
  • Voice AI
  • Chat
  • Email
  • SMS
  • WhatsApp

Features

  • All Features
  • High-Volume Operations
  • Multi-Party Collaboration
  • Contract Renewals
  • Compliance & Audit
  • Pricing
  • Case Studies
  • Customers
  • Why SwiftCase

Company

  • About
  • Our Team
  • Adam Sykes
  • Nik Ellis
  • Implementation
  • 30-Day Pilot
  • Operations Pressure Map
  • For Your Role
  • Peer Clusters
  • Engineering
  • Careers
  • Partners
  • Press
  • Research
  • Tech Radar
  • Blog
  • Contact

Resources

  • Use Cases
  • Software
  • ROI Calculator
  • Pressure Diagnostic
  • Pilot Scope Estimator
  • Board Case Builder
  • Free Tools
  • Guides & Templates
  • FAQ
  • Compare
  • Glossary
  • Best Practices
  • Changelog
  • Help Centre

Legal

  • Privacy
  • Terms
  • Cookies
  • Accessibility

Stay in the loop

Cyber Essentials CertifiedGDPR CompliantUK Data Centres

© 2026 SwiftCase. All rights reserved.

Switchboard

AIthattakes
realaction.

Switchboard makes real API calls during conversations. Five production tools — search case, verify identity, look up status, update field, create case. Every call schema-validated, permission-bound, and Timeline-logged.

See an example call
Scope a 30-day pilot

The difference between “chatbot” and “agent.”

Not a chatbot

Most AI assistants can read your knowledge base and tell you what your policy says. Switchboard can update your policy, log a claim, schedule the survey, and confirm the appointment — during the same call.

Real action, not advice

When a customer asks “can you update my email address?” the AI does it (after identity verification). It does not tell the customer to log into the portal. It does not promise to pass it on to a handler.

Every call logged

Every tool invocation is a Timeline entry: actor (agent definition + version), timestamp, resource (case + field), outcome (success/failure/partial), severity. Auditable, exportable, attributed.

Permission-bound

Each tool requires the prerequisites it needs. Update operations require a verified session. Sensitive fields require additional confirmation. Out-of-policy requests trigger escalation, not workarounds.

The Five Tools

Each tool has a schema, a permission, and an audit trail.

These are the production tools the AI uses on every regulated conversation. Custom tools live alongside them.

search_case

Search a case

Look up an existing case by registration plate, phone number, email, postcode, or customer name. The AI fetches the case file and any open workflow state before continuing the conversation.

Inputs

  • Vehicle registration
  • Phone number (E.164 normalised)
  • Email address
  • Postcode + name combination
  • Direct case reference

Outputs

Matched case ID, case status, owner, last activity, open tasks. Multiple matches surface as a disambiguation step.

Severity

Low — read-only.

verify_identity

Verify identity

Two-step verification on different fields: typically date of birth + postcode, or memorable info + reference. Issues a verified-session token that lasts 30 minutes. Verification is required before any case detail is shared.

Inputs

  • Two distinct identifying fields per agent definition
  • Configurable per case type and channel
  • Failed-attempt threshold per agent

Outputs

Verified session (30-min default) bound to channel + case + caller. Failure routes to handler with diagnostic.

Severity

Medium — gates all subsequent tool use on the case.

lookup_status

Look up status

Fetch the current status of a case, sub-case, or task. By task ID, by reference, or by relationship to the active case. Supports the 'where is my claim?' conversation without escalating to a handler.

Inputs

  • Task ID or reference
  • Sub-case ID
  • Workflow stage filter
  • Date range filter

Outputs

Current status, last update timestamp, expected next milestone, any blockers flagged.

Severity

Low — read-only on verified sessions.

update_field

Update a field

Write a new value to a structured field on the case. Natural-language aliasing maps customer phrasing to canonical field names — “car reg” → vehicle_registration, “mobile” → phone_mobile. Validation runs before commit.

Inputs

  • Field name (or alias)
  • New value
  • Verified session token
  • Optional change reason

Outputs

Updated field value, prior value preserved in Timeline, confirmation message rendered to caller.

Severity

Medium — write to case file, attributed to caller via verified session.

create_case

Create a new case

Open a new case from scratch with workflow discovery — the AI selects the right workflow definition based on case type, customer, and conversation context. Used heavily for FNOL intake.

Inputs

  • Case type (or AI-discovered from conversation)
  • Workflow ID (or AI-discovered)
  • Initial structured fields
  • Customer link (if verified)

Outputs

New case ID, workflow attached, initial routing applied, follow-up tasks scheduled.

Severity

Medium — creates new resource, full Timeline trail.

Example Call

FNOL intake, ten lines.

An anonymised slice of a Switchboard FNOL call. Tool calls render inline so you can see what the AI is doing as the conversation unfolds.

Hi, I had a bump this morning. I want to put in a claim.

Switchboard

I'm sorry to hear that. Are you OK? Let me get you set up. Can you give me your registration plate first?

Yeah, AB12 CDE.

search_case→ Existing case found · Customer: J. Smith · Policy active
Switchboard

Thanks. I've got your details. To confirm I'm speaking to John Smith, can I ask for your date of birth and the first line of your address?

12 March 1985. 47 Acacia Avenue.

verify_identity→ Verified · Session valid 30 min · Channel: voice
Switchboard

Thanks John, you're verified. I'm going to take you through what happened. When and where did the incident occur?

create_case→ New FNOL case CL-184932 · Workflow: motor-fnol-v3 · Routed to first-notification queue
Switchboard

I've opened your claim — the reference is CL-184932. Now, in your own words, what happened?

Every tool call is a Timeline event. Three tool invocations in this slice — search_case, verify_identity, create_case — each with actor, timestamp, resource, outcome, and severity logged. The case file reflects the conversation in real-time; the audit trail is complete before the call ends.

FAQ

The architecture and procurement questions.

Can the AI do anything outside these five tools?

Switchboard executes only the tools defined in its agent configuration. Anything outside that scope routes to a human handler with the conversation context. New tools can be added to the configuration during onboarding (or later) — they need an API endpoint, an input/output schema, and a permission policy. Once defined, the AI can use them; until then, it cannot.

What stops the AI from calling the wrong tool?

Tools are scoped per agent definition. A TL-settlement agent has tools for case lookup and structured response capture; it does not have a create_case tool because TL is not a new-case conversation. Within the agent's allowed toolset, the LLM selects which tool fits the conversation — and the platform validates inputs against the schema before execution. Mismatches fail closed and escalate to a handler.

How does natural-language aliasing work?

Each writable field has a canonical name plus a configurable alias list. “Car reg,” “numberplate,” “reg,” and “vehicle registration” all alias to vehicle_registration. The AI resolves aliases automatically. Aliasing rules are configured per tenant — easy to extend for industry-specific phrasing.

What happens if a tool call fails?

Tool failures are logged in Timeline with the diagnostic (timeout, validation failure, downstream error). The AI either retries (for transient failures), asks the caller a clarifying question (for input ambiguity), or escalates to a handler with the partial conversation and the failure reason. The caller is never told “the system is broken” without a path to a human.

Can we add custom tools for our specific case types?

Yes. Custom tools are part of agent configuration. Common additions in claims include: book_survey, schedule_callback, link_to_third_party, fetch_policy_document, send_consent_form. Each follows the same pattern — schema, permissions, severity, Timeline-logged. Most custom tools are added during the 30-day pilot.

How is this different from the ‘function calling’ in raw OpenAI/Anthropic APIs?

Function calling is the LLM-side mechanic. Switchboard adds the operational layer around it — schema validation, permission policy, identity-binding, audit logging in Timeline, escalation on failure, multi-LLM routing so the same tool call works across providers. Building this from scratch on top of raw function calling is a 12-month project; we have it as platform infrastructure.

Pilot the toolset on your busiest conversation.

Run Switchboard alongside your existing process for 30 days. Watch the tool-call volume, the verification rate, the case-creation throughput. Decide.

Scope a 30-day pilot
See Timeline audit trail