Understand
Identify intent, urgency, language, entities, and missing information.
Home / How it works
How Claire works
From request to completed work.
Claire turns a customer or staff request into a governed workflow. She understands the need, retrieves permitted context, coordinates the systems involved, applies configured rules, and either completes the next action or brings in the right person.
RequestVoice, chat, message, form, event, or system trigger
ContextAuthorized records, conversation history, and workflow
state
Claire orchestrationRouting, policy, tool coordination, AI workers, and
escalation
OutcomeCompleted action, confirmed next step, or informed human
handoff
The operating sequence
Conversation is one input. Resolution is the job.
A chatbot can answer a question and stop. Claire maintains state across the work that follows, including system lookups, scheduling rules, document requirements, approvals, exceptions, and follow-up.
Retrieve
Request only the authorized data needed for this workflow and person.
Coordinate
Call the configured systems and AI workers in the required sequence.
Decide
Apply business policy, permissions, thresholds, and exception logic.
Act or escalate
Complete permitted actions or hand the case to a human with context.
Configured boundaries
Claire does not invent the job.
Deployment begins by defining what the workflow may access, which actions it may take, and which conditions require a person.
- PermissionsWhich records, tools, functions, and fields are available.
- Business rulesEligibility, scheduling, routing, service, or approval policies.
- Escalation triggersRisk, ambiguity, emotion, exception, professional judgment, or required authorization.
- TraceabilityInputs, tool activity, decisions, workflow state, and handoffs.
Implementation
Start with one workflow that matters.
The practical first deployment is not “add AI everywhere.” It is a bounded workflow with enough repetition to matter and clear enough rules to operate safely.
1. Map the work
Document the request, systems, decision points, failure modes, service levels, and human owners.
2. Configure and test
Connect permitted tools, define rules and escalation, test normal paths and exceptions, and establish acceptance criteria.
3. Operate and improve
Launch with observability, review outcomes and handoffs, and expand responsibility only when evidence supports it.
Show us the workflow.
We will map what Claire can own, which systems are involved, and where humans remain in control.
A workflow is more than a conversation
Follow the request until the next owner and outcome are clear.
Claire can begin with a call, message, form, schedule, campaign, or configured event. The incoming language is converted into usable context: who is asking, what they need, which record is relevant, what facts are missing, and what outcome the person expects.
The workflow can then collect information, present options, capture keypad input, retrieve documents, set variables, evaluate conditions, check time, route a decision, call an authorized API, send SMS or email, wait for another event, run a sub-workflow, coordinate parallel steps, or bring in a person. These are product primitives; the customer-specific sequence, permissions, and integration access still require configuration and testing.
Normal path
Define the common request, required facts, permitted action, system result, confirmation, and completed state.
Exception path
Define missing data, conflicting records, unavailable systems, timeouts, failed actions, policy ambiguity, and the person who owns each exception.
Human path
Choose where a person approves, decides, takes over, or receives a completed preparation task. Include the context and attempted actions.
Improvement path
Use runtime, operations, recordings, and quality review to find repeated friction before expanding the workflow’s responsibility.
A successful pilot establishes a baseline before automation: current volume, handling time, completion rate, handoffs, abandoned requests, rework, and failure categories. Expansion should follow verified operational outcomes, not the number of conversations processed.
Implementation owners should approve a written workflow contract: trigger, required context, source of truth, permitted actions, human checkpoints, timeout, retry behavior, exception owner, completion state, and evidence retained. This prevents a successful conversation from being mistaken for successful operations and gives quality reviewers a stable definition of correct behavior.
During review, compare the recorded request with the state changes and final system result. Sample both completed and escalated work so recurring exceptions become configuration, integration, training, or product decisions.