Run 50 scenarios across every relevant channel: five case types in ten domains. Score fact consistency, required information, action state, context continuity, employee handoff, and customer honesty. Require 90% overall and zero critical failures before broad release.
Cross-channel consistency must be tested—not assumed
A business can publish correct information on its website while the phone agent gives an old policy, the chatbot invents a price, and the app displays an outdated reward. Each interface may pass its own demo. The customer still experiences one business, so the system fails when channels disagree or lose context.
The “one business brain” test is a cross-channel quality-assurance plan for a phone agent, web chatbot, SmartSite, customer app, forms, booking, and employee dashboard. It tests facts, identity, corrections, action states, handoffs, consent, live data, failures, and updates. The goal is not identical wording. The goal is consistent truth and coordinated operations.
Direct answer
Run the same 50 scenarios through every relevant channel and compare the underlying fact, required information, action state, handoff, and customer promise. Any channel may phrase the response differently, but it must not create a different rule, record, or outcome.
The 10 cross-channel test domains
| Domain | What to test | Critical failure |
|---|---|---|
| 1. Business identity | Name, service area, hours, phone, location, contact path. | A channel routes to the wrong business or unavailable service. |
| 2. Services and boundaries | Offered work, exclusions, preparation, lead times, pricing limits. | Invented service, price, availability, or policy. |
| 3. Customer identity | New vs existing, duplicate match, verification, correction. | Private data shown to the wrong person. |
| 4. Required intake | Same minimum fields and conditional questions. | One channel creates an unusable or misleading record. |
| 5. Live state | Calendar, order, capacity, reward, or status read. | Stale state presented as current. |
| 6. Actions | Record, message, booking, upload, reward, or assignment. | Success claimed without destination evidence. |
| 7. Handoffs | Summary, owner, deadline, unresolved items, transcript/source. | Urgent or customer-impacting work has no owner. |
| 8. Corrections | Changed name, number, date, address, service, or decision. | Old and new values are both treated as valid. |
| 9. Consent and preference | Channel permission, opt-out, contact timing, accessibility. | Communication continues after opt-out or without required permission. |
| 10. Change propagation | One approved policy or service update across channels. | A production channel keeps the old rule after release. |
Build the 50-case test set
Create five cases for each domain: an ordinary case, an incomplete case, a correction, a boundary case, and a failure or conflict. Reuse representative customer language from real inquiries after removing unnecessary personal information. The test set should include customers who ask two questions, interrupt, change direction, use informal language, provide details out of order, and move from one channel to another.
| Case type | Example | Expected result |
|---|---|---|
| Ordinary | Customer asks whether a standard service is offered and requests next steps. | Every channel gives the approved answer and the appropriate channel-specific next action. |
| Incomplete | Customer wants an estimate but omits the address and project type. | Every intake route preserves the request and gathers the same required minimum fields. |
| Correction | Customer changes the preferred date and corrects the phone number. | The authoritative record is updated; old values remain history, not active instructions. |
| Boundary | Customer is near the service-area edge or asks for a variable price. | Every channel applies the same approved boundary and escalation. |
| Failure | Calendar or message destination is unavailable. | No channel claims completion; an exception and customer-safe state are created. |
Score each case on six dimensions
| Dimension | Points | Passing evidence |
|---|---|---|
| Fact consistency | 0–2 | The underlying business fact matches the approved source across channels. |
| Information consistency | 0–2 | Required fields and qualification rules align without unnecessary duplication. |
| Action-state consistency | 0–2 | Requested, pending, confirmed, failed, canceled, and completed mean the same thing. |
| Context continuity | 0–2 | Verified prior information carries forward and corrections replace active values. |
| Handoff quality | 0–2 | Employees receive owner, deadline, facts, unresolved items, source, and evidence. |
| Customer safety and honesty | 0–2 | No invented authority, private-data exposure, or false completed action. |
The full test set is worth 600 points. Require at least 540 points, or 90%, before broad release—but critical failures override the total. A single privacy exposure, false payment or booking confirmation, unsafe instruction, or unowned urgent handoff requires repair and retesting.
Run channel-transition tests
Website to phone
Start a request on the site, then call. Verify identity, existing facts, missing fields, and current state.
Phone to app
Create a pending request by phone, then open the app. Verify only appropriate information appears and the status is accurate.
Chat to employee
Complete chatbot intake and inspect the employee handoff. Verify summary, transcript, source, owner, deadline, and unresolved item.
Employee correction to every channel
Change one approved customer or policy field. Verify active records and public answers update without exposing internal notes.
Failed action across channels
Force a calendar or messaging failure. Verify phone, chat, web confirmation, app, and dashboard show compatible pending or failed states.
Opt-out propagation
Opt out through one channel. Verify future automated communication honors the preference across connected channels.
Test the business-brain update process
Choose one harmless but visible business change—such as a preparation instruction, holiday hour, service-name clarification, or lead-time boundary. Process it through the real update workflow. Record who approved it, which source changed, which channels consume the source, which tests run, when it was released, and how rollback works.
Do not edit each channel manually unless the architecture requires a channel-specific presentation change. Manual duplication creates drift. Where channel-specific instructions exist, they should inherit the approved core fact and add only the formatting or interaction needed for that channel.
Strong update control
- One approved source change.
- Named approver and version.
- Affected-channel list.
- Regression tests before release.
- Release record and rollback.
- Post-release sample verification.
Drift-producing update
- Owner texts different wording to multiple vendors.
- Prompts are edited live.
- No one knows which channel uses which file.
- Old answers remain cached indefinitely.
- No regression test after a policy change.
Inspect the employee view—not only the customer view
A consistent customer experience depends on an employee record that tells the truth. The dashboard should show the customer, verified contact, channel history, current request, facts collected, action state, system evidence, owner, deadline, unresolved questions, and any exception. It should not force employees to compare three transcripts and two inboxes.
| Employee-view element | Purpose | Failure to avoid |
|---|---|---|
| Unified timeline | Shows what happened across channels and when. | Employees contact the customer without seeing a recent interaction. |
| Active values | Shows current phone, date, service, address, and preference. | Corrected data competes with older values. |
| Action evidence | Links calendar ID, message result, record ID, upload, or payment state. | Dashboard says completed with no source proof. |
| Ownership | Shows person or queue and response deadline. | Notification exists but nobody accepts it. |
| Exception state | Shows reason, impact, retry, and resolution. | Failures disappear inside technical logs. |
| Customer promise | Records exactly what was stated or confirmed. | Employee unintentionally contradicts the system. |
Common cross-channel failures and their root causes
| Observed failure | Likely root cause | Corrective action |
|---|---|---|
| Phone says service is available; web says it is not. | Separate knowledge copies or unclear source hierarchy. | Choose authoritative source, remove duplicate facts, and regression-test all channels. |
| Customer repeats information after switching channels. | No shared request ID or identity verification flow. | Create shared record and secure lookup process. |
| App shows confirmed while calendar has no event. | Local app state updated before destination confirmation. | Write action state only from verified calendar result. |
| Chat collects different fields than phone. | Channel teams designed intake independently. | Define shared minimum schema and approved channel-specific additions. |
| Employee receives long transcripts but no action. | No structured handoff model. | Create summary, owner, deadline, unresolved items, and evidence. |
| Old policy persists in one channel. | Manual updates and no channel inventory. | Centralize core knowledge and add change-propagation tests. |
| Opt-out honored in text but not app push. | Consent stored separately by channel. | Use shared preference record with channel-specific permissions. |
Run a monthly one-business-brain audit
- Sample five real journeys that used more than one channel.
- Run ten rotating regression cases from the 50-case library.
- Review every critical or repeated exception and assign root cause.
- Check knowledge freshness for prices, services, hours, policies, and preparation.
- Verify account access and exports for the shared record and business brain.
- Compare customer promises to destination evidence.
- Review consent and opt-out propagation.
- Approve, test, and document changes before the next release.
Monthly testing should be risk-based. A seasonal business may test special hours and offers before each change. A business with frequent scheduling updates may test live-state reads weekly. The key is a permanent test library rather than a one-time launch event.
Use the test to choose a Fayetteville builder
Ask any company offering phone agents, chatbots, websites, or apps to run a cross-channel demonstration using your test cases. Do not accept a tour of separate polished screens. Watch one customer record move, change, fail, hand off, and recover.
The connected AI stack architecture explains how the layers should fit. Review Fayetteville Artificial Intelligence’s connected business systems, then apply the same 50-case standard to every candidate. To test your current channels, request a one-business-brain audit.
Frequently asked questions
Should the phone agent and chatbot give identical wording?
No. Wording should fit the channel. The approved fact, boundary, required information, action state, and customer promise must remain consistent.
How many tests are enough?
This framework uses 50 cases: five patterns across ten domains. Add industry-specific, safety, financial, accessibility, and seasonal tests where consequences require them.
What is a critical failure?
Private-data exposure, invented price or policy, unsafe instruction, false booking or payment confirmation, ignored opt-out, or an unowned urgent handoff should fail release regardless of total score.
How often should cross-channel tests run?
Run the full suite before launch and major architecture changes. Run focused regression cases after every knowledge, workflow, integration, or channel change, plus a rotating monthly audit.
What if one channel needs extra intake fields?
Channel-specific fields are acceptable when justified. They should extend the shared minimum record without changing the underlying service, qualification, or action-state rules.
Make every channel tell the same operational truth.
Fayetteville Artificial Intelligence can build or audit the shared business brain, customer record, action states, handoffs, consent, and regression tests across phone, web, chat, app, and automation.
Editorial standard: practical, business-specific, customer-facing, and honest about limitations. Examples are illustrative unless explicitly identified as measured business data. Updated when technology, local operating conditions, or implementation standards materially change.