Zaha AI / mConsent
Step-by-step implementation guide — pre-implementation checklist, onboarding, staff training, go-live runbook, and ROI tracking.
Zaha AI / mConsent — Implementation Playbook (DSO)
Implementation Playbook: Zaha AI / mConsent
AI Receptionist Solution for Dental Service Organizations
1. Executive Summary
What This Tool Does
Zaha AI's mConsent is an AI-powered receptionist platform that automates patient intake, appointment scheduling, insurance verification, and front-desk communications through intelligent conversational AI. The system handles inbound calls, text messages, and digital forms while seamlessly integrating with practice management systems to reduce administrative burden and eliminate missed calls.
Why DSOs Specifically Benefit from AI Receptionists
AI receptionist technology delivers compounding value at scale for DSOs:
- Standardization: Consistent patient experience across all locations—every call answered identically, every intake form completed the same way, eliminating variability from staff turnover or training gaps
- Data Aggregation: Centralized visibility into call volumes, scheduling patterns, no-show predictions, and patient communication metrics across your entire portfolio—intelligence that single practices cannot access
- Labor Arbitrage: Front desk staffing is one of the highest turnover positions in dentistry; AI receptionists reduce dependency on a volatile labor market while freeing existing staff for higher-value patient interactions
- Scalability Without Headcount: Add locations without proportionally adding administrative staff; the AI handles volume increases without incremental cost per call
- After-Hours Capture: 35-40% of patient calls occur outside business hours; capturing these across 15-50 locations represents significant revenue recovery
Expected Timeline: Decision to Full Deployment
| Phase | Timeline | Scope |
|---|---|---|
| Pre-Implementation | Weeks 1-2 | Vendor contracts, technical readiness, baseline metrics |
| Wave 1 Pilot | Weeks 3-6 | 2-3 pilot locations |
| Wave 2 Expansion | Weeks 7-12 | Next 5-8 locations |
| Wave 3 Full Deployment | Weeks 13-20 | Remaining locations |
| Optimization & Stabilization | Weeks 21-24 | Performance tuning, ROI validation |
Total: 5-6 months for a 30-location DSO, with first locations live by Week 6.
2. Pre-Implementation Checklist (Weeks 1–2)
Technical Requirements
Hardware Requirements
☐ Verify all locations have computers meeting minimum specs (Windows 10+ or macOS 11+, 8GB RAM minimum) ☐ Confirm reliable internet connectivity: minimum 25 Mbps download/10 Mbps upload per location ☐ Assess current phone system compatibility (VoIP preferred; POTS lines may require adapters) ☐ Inventory headset/audio equipment for staff monitoring AI interactions ☐ ⚠️ Identify locations with outdated phone systems requiring upgrade before deployment
Software Requirements
☐ Document PMS version at each location (Dentrix, Eaglesoft, Open Dental, or other) ☐ Verify PMS versions meet mConsent integration requirements 🔵 ☐ Confirm browser compatibility (Chrome or Edge recommended) ☐ Document existing digital intake solutions to be deprecated ☐ Assess imaging software if appointment-type routing will reference imaging needs
Network Requirements
☐ Test network latency at each location (<100ms to cloud services) ☐ Verify firewall configurations allow outbound connections to mConsent servers 🔵 ☐ Document any locations with restrictive IT environments (hospital-owned buildings, shared medical complexes) ☐ Assess VPN or SD-WAN configurations that may affect cloud connectivity
Vendor Onboarding Steps & Key Contacts
Establish Vendor Relationships (Week 1)
| Role | Purpose | Contact Method |
|---|---|---|
| Account Executive | Contract, pricing, escalations | Direct line + email |
| Implementation Manager | Technical deployment lead | 🔵 Assigned at kickoff |
| Technical Support Tier 1 | Day-to-day troubleshooting | Support portal + phone |
| Technical Support Tier 2 | Integration issues, complex problems | Escalation from Tier 1 |
| Customer Success Manager | Ongoing optimization, renewals | Monthly check-ins |
Onboarding Milestones
☐ 🔵 Complete vendor kickoff call (schedule within 3 days of contract execution) ☐ 🔵 Receive implementation timeline and assigned resources from vendor ☐ Sign Business Associate Agreement (BAA) if not included in master agreement ☐ 🔵 Obtain access to vendor's implementation portal/project management tool ☐ 🔵 Schedule technical discovery call with vendor's integration team ☐ Establish escalation matrix with vendor (response time SLAs by severity)
Data/Access Prerequisites
System Access Requirements
☐ Create master admin credentials for mConsent platform ☐ Provision API access to PMS (requires PMS admin credentials per location) ☐ 🔵 Submit API key requests to PMS vendors (Dentrix Enterprise, Eaglesoft, etc.)—allow 5-10 business days ☐ Compile location-specific credentials in secure password vault ☐ Document existing phone system admin access per location ☐ Gather insurance verification portal credentials if mConsent will handle eligibility
Data Preparation
☐ Export provider schedules and appointment type configurations per location ☐ Document current call routing rules and phone tree structures ☐ Compile list of appointment types and average durations ☐ ⚠️ Identify locations with non-standard scheduling rules requiring custom configuration ☐ Document after-hours protocols by location (answering service, voicemail, forwarding)
Internal Stakeholder Alignment
🟣 Approval Requirements
| Decision | Approver | Information Needed |
|---|---|---|
| Budget approval | CFO/CEO | Total investment, ROI projections, payment terms |
| Rollout timeline | VP Operations | Resource requirements, location disruption assessment |
| Data governance | Compliance/Legal | BAA review, data handling, HIPAA verification |
| IT resource allocation | IT Director | Integration effort, security review, network changes |
| Clinical workflow changes | Chief Dental Officer | Provider impact, clinical communication flows |
Communication Requirements
| Stakeholder | When to Inform | What They Need to Know |
|---|---|---|
| Board/Investors | 🟣 Before contract signing | Strategic rationale, expected ROI, risk mitigation |
| C-Suite | Weeks 1-2 | Full implementation plan, resource asks, timeline |
| Regional Managers | Week 2 | Their role in rollout, location selection criteria, support expectations |
| Office Managers | Week 2-3 | What's changing, timeline for their location, training expectations |
| Providers | Week 3-4 | Minimal disruption message, benefits framing |
Baseline Metrics to Capture
⚠️ Critical: Standardize Measurement Before Go-Live
Without consistent baseline metrics, ROI cannot be validated. Establish identical measurement methodology across all locations.
Core Metrics (Mandatory)
| Metric | Measurement Method | Target Collection Period |
|---|---|---|
| Total inbound calls | Phone system reports | Previous 90 days |
| Missed/abandoned calls | Phone system reports | Previous 90 days |
| Average hold time | Phone system reports | Previous 90 days |
| After-hours call volume | Phone system reports | Previous 90 days |
| New patient calls | Front desk tracking | Previous 30 days |
| New patient conversion rate | New patient calls → scheduled appointments | Previous 30 days |
| Time to answer | Phone system reports | Previous 30 days |
| Front desk FTEs | HR/Payroll | Current |
| Front desk labor cost | HR/Payroll | Previous 90 days |
| No-show rate | PMS reports | Previous 90 days |
| Confirmation completion rate | Manual tracking or existing system | Previous 30 days |
Secondary Metrics (Recommended)
| Metric | Measurement Method | Target Collection Period |
|---|---|---|
| Patient satisfaction scores | Survey tool or Google reviews | Previous 6 months |
| Online scheduling adoption | PMS or scheduling tool | Previous 90 days |
| Insurance verification turnaround | Manual tracking | Previous 30 days |
| Form completion rate (pre-appointment) | Current intake system | Previous 30 days |
🟣 Executive Decision Required
Determine who owns baseline data collection—central analytics team vs. regional managers vs. office managers. Recommend: Central analytics team pulls automated reports; office managers validate accuracy.
Enterprise-Level Requirements
Network Standards Across Locations
☐ Document network architecture: centralized vs. distributed management ☐ Identify locations on managed networks vs. independent ISPs ☐ ⚠️ Flag locations with network change restrictions (landlord-managed, shared spaces) ☐ Establish minimum network requirements in location standards document ☐ Plan for network upgrades at underperforming locations (budget + timeline)
Hosting Architecture Decision
| Option | Pros | Cons | Recommendation |
|---|---|---|---|
| Centralized Hosting | Single configuration, easier management | Single point of failure, may require more robust network | Recommended for DSOs with standardized IT |
| Location-Level Hosting | Location independence, redundancy | Configuration drift, harder to maintain | Consider only if network reliability varies significantly |
🟣 Executive Decision Required: Confirm hosting architecture preference with IT and vendor.
Single Sign-On (SSO) Integration
☐ Document current SSO provider (Okta, Azure AD, Google Workspace) ☐ 🔵 Confirm mConsent SSO compatibility and integration requirements ☐ Plan SSO integration timeline (typically adds 1-2 weeks to implementation) ☐ ⚠️ Identify locations with non-standard identity management requiring workarounds
Centralized Credentialing
☐ Establish role-based access control (RBAC) structure for mConsent ☐ Define user roles: Super Admin (central), Location Admin, Staff User, Read-Only ☐ Document credential provisioning workflow for new hires ☐ Establish offboarding protocol for credential revocation
3. Location Readiness Assessment
Scoring Framework
Rate each location 1-5 on the following factors, then calculate composite scores to determine rollout sequence.
Factor 1: IT Infrastructure Maturity
| Score | Network Speed | Hardware Age | PMS Version | Phone System |
|---|---|---|---|---|
| 5 | >100 Mbps | <2 years | Current/supported | Modern VoIP |
| 4 | 50-100 Mbps | 2-3 years | 1 version behind | VoIP, basic |
| 3 | 25-50 Mbps | 3-4 years | 2 versions behind | Digital POTS |
| 2 | 10-25 Mbps | 4-5 years | 3+ versions behind | Analog POTS |
| 1 | <10 Mbps | >5 years | Unsupported | Legacy/problematic |
Factor 2: Staff Tenure and Adaptability
| Score | Turnover Rate | Tech Comfort | Training History |
|---|---|---|---|
| 5 | <15% annual | Early adopters, tech-forward | Strong training completion rates |
| 4 | 15-25% annual | Comfortable with technology | Good training engagement |
| 3 | 25-35% annual | Average tech comfort | Moderate training compliance |
| 2 | 35-50% annual | Resistant to new tools | Training challenges |
| 1 | >50% annual | Technology-averse | Significant training issues |
Factor 3: Patient Volume
| Score | Daily Patient Volume | Complexity | Risk/Impact Balance |
|---|---|---|---|
| 5 | High (40+ patients/day) + stable ops | Manageable | High impact, manageable risk |
| 4 | Medium-high (30-40) + stable ops | Manageable | Good balance |
| 3 | Medium (20-30) | Moderate | Moderate both |
| 2 | Low (10-20) or high + unstable | Complex | Lower impact or higher risk |
| 1 | Very low (<10) or chaotic ops | Very complex | Not worth early investment |
Factor 4: Existing Tech Stack Compatibility
| Score | PMS Compatibility | Imaging Integration | Other Integrations |
|---|---|---|---|
| 5 | Native integration available | Fully compatible | All systems supported |
| 4 | API integration available | Compatible | Most systems supported |
| 3 | Integration requires configuration | Limited compatibility | Some workarounds needed |
| 2 | Custom integration required | Incompatible | Significant workarounds |
| 1 | No viable integration path | Not possible | Major blockers |
Factor 5: Local Champion Availability
| Score | Champion Profile |
|---|---|
| 5 | Tech-forward provider or OM, enthusiastic, influential with team, available for training role |
| 4 | Capable OM or senior staff, supportive, can lead training |
| 3 | Willing staff member, but limited influence or availability |
| 2 | No clear champion, but no active resistance |
| 1 | No champion, active resistance from leadership |
Composite Scoring Calculation
Formula: Composite Score = (IT × 1.5) + (Staff × 1.5) + (Volume × 1.0) + (Tech Stack × 1.5) + (Champion × 1.5)
Maximum Possible Score: 35 points
Rollout Tier Recommendations
| Composite Score | Rollout Tier | Timing |
|---|---|---|
| 28-35 | Wave 1 (Pilot) | Weeks 3-6 |
| 21-27 | Wave 2 | Weeks 7-12 |
| 14-20 | Wave 3 | Weeks 13-20 |
| <14 | Remediation Required | Address blockers before rollout |
Sample Location Assessment Matrix
| Location | IT Score | Staff Score | Volume Score | Tech Score | Champion Score | Composite | Wave |
|---|---|---|---|---|---|---|---|
| Downtown Main | 5 | 4 | 4 | 5 | 5 | 32.5 | 1 |
| Suburban West | 4 | 5 | 3 | 4 | 4 | 28.5 | 1 |
| Eastside Family | 4 | 4 | 4 | 4 | 4 | 28.0 | 1 |
| North Campus | 3 | 4 | 3 | 4 | 3 | 23.5 | 2 |
| Mall Location | 3 | 3 | 5 | 3 | 3 | 23.5 | 2 |
| ... | ... | ... | ... | ... | ... | ... | ... |
Rollout Sequence Recommendations
Wave 1 Selection Criteria (2-3 Locations)
- Highest composite scores (28+)
- Geographic diversity (different regions if applicable)
- Mix of practice types (GP, specialty, pediatric) if portfolio includes variety
- Avoid: flagship location (too high stakes), troubled locations (too many variables)
- ⚠️ Do not select your highest-revenue location for Wave 1—pilot risk should be manageable
Wave 2 Expansion Criteria (5-8 Locations)
- Composite scores 21-27
- Learn from Wave 1: prioritize locations similar to successful pilots
- Begin including higher-volume locations once processes are proven
- Address any IT/compatibility issues identified in Wave 1 before Wave 2 begins
Wave 3 Full Deployment
- All remaining locations
- By this point, playbook is battle-tested
- Focus on locations requiring remediation (IT upgrades, change management)
4. Rollout Strategy
Wave Structure
| Wave | Locations | Duration | Gap to Next Wave |
|---|---|---|---|
| Wave 1 (Pilot) | 2-3 | 4 weeks | 2 weeks learning capture |
| Wave 2 (Early Expansion) | 5-8 | 4 weeks | 1 week learning capture |
| Wave 3 (Full Deployment) | Remaining | 6-8 weeks | N/A |
Wave 1: Pilot Phase (Weeks 3-6)
Selection Criteria for Pilot Locations
☐ Composite readiness score 28+ ☐ Strong local champion identified and committed ☐ Representative of broader portfolio (avoid outliers) ☐ Manageable risk profile (not highest revenue, not most complex) ☐ Geographic accessibility for central team on-site support if needed ☐ 🟣 Final pilot location selection approved by VP Operations
Wave 1 Timeline
| Week | Activities |
|---|---|
| Week 3 | 🔵 Vendor technical setup, integrations, test environment |
| Week 4 | Champion training, staff training, parallel run begins |
| Week 5 | Go-live with monitoring, daily check-ins |
| Week 6 | Optimization, issue resolution, documentation |
Parallel Run Period
- Duration: 3-5 business days before full go-live
- What it means: AI receptionist active but staff monitors 100% of interactions, ready to intervene
- Success criteria: AI handles >80% of interactions correctly without intervention
- ⚠️ Do not skip parallel run—this is where you catch configuration issues before they affect patients
Daily Check-In Cadence (Wave 1)
- Day 1-5: 15-minute standup with location champion, regional manager, vendor support
- Day 6-10: 30-minute daily debrief, focus on edge cases and optimization
- Day 11+: Move to weekly check-ins if metrics are stable
Escalation Path
| Issue Type | First Contact | Escalation | Response SLA |
|---|---|---|---|
| Technical outage | 🔵 Vendor Tier 1 | Vendor Tier 2 | 1 hour |
| Integration failure | Central IT + Vendor | Vendor Tier 2 | 4 hours |
| Configuration question | Location Champion | Regional Manager | Same day |
| Patient complaint | Office Manager | VP Operations | Same day |
| Staff resistance | Location Champion | Regional Manager + HR | 24 hours |
Wave 2: Early Expansion (Weeks 7-12)
Pre-Wave 2 Learning Capture (Week 7-8)
☐ Debrief sessions with Wave 1 champions—what worked, what didn't ☐ Document configuration adjustments made during Wave 1 ☐ Update training materials based on Wave 1 feedback ☐ Revise go-live checklist based on Wave 1 issues ☐ 🟣 Present Wave 1 results to C-suite, confirm go/no-go for Wave 2
Go/No-Go Criteria for Wave 2
Go Criteria (must meet all): ☐ Wave 1 locations stable for 5+ consecutive business days ☐ <3 critical issues unresolved ☐ Staff satisfaction survey >60% positive ☐ Patient-facing interactions achieving >85% successful completion ☐ No data/HIPAA incidents
No-Go Triggers (any one blocks advancement): ☐ Unresolved integration failures affecting core functionality ☐ Staff walkout or mass resistance ☐ Patient complaint rate >2% of interactions ☐ Data breach or HIPAA incident
Wave 2 Timeline
| Week | Activities |
|---|---|
| Week 7-8 | Learning capture, Wave 2 prep, champion training |
| Week 9 | Technical setup for Wave 2 locations (parallelize with vendor) |
| Week 10 | Staff training, parallel run |
| Week 11 | Go-live, intensive monitoring |
| Week 12 | Stabilization, documentation update |
Wave 3: Full Deployment (Weeks 13-20)
Acceleration Factors
By Wave 3, processes are mature. Accelerate by:
- Training multiple locations simultaneously via video
- Deploying 3-4 locations per week instead of 2-3
- Reducing parallel run to 2-3 days for straightforward locations
- Leveraging Wave 1-2 champions as peer mentors
Wave 3 Timeline (Example: 20 Remaining Locations)
| Week | Locations Deployed | Cumulative |
|---|---|---|
| 13-14 | 4 | 14-19 total |
| 15-16 | 5 | 19-24 total |
| 17-18 | 5 | 24-29 total |
| 19-20 | 6 | 30-35 total |
Rollback Plan
⚠️ If a Wave Fails
Definition of Wave Failure:
- 2+ locations in the wave experiencing critical, unresolved issues after 10 business days
- Integration failure affecting >50% of functionality
- Patient-facing error rate >5%
Rollback Procedure:
Pause (Day 1 of failure recognition) ☐ Halt any new location deployments ☐ Do not revert stable locations—isolate the problem ☐ Convene emergency call: VP Ops, IT, vendor, regional managers
Assess (Days 2-3) ☐ Root cause analysis with vendor ☐ Determine if issue is location-specific or systemic ☐ Document impact on patients and staff
Decide (Day 4) 🟣 Executive decision required:
- Option A: Fix forward (resolve issue, extend timeline, continue)
- Option B: Rollback affected locations, fix, re-deploy
- Option C: Pause entire program, major re-scoping needed
Execute (Days 5+) ☐ If rollback: revert to previous phone system/intake process ☐ Communicate to staff: "We're pausing to get this right" ☐ Communicate to patients: minimal disruption message ☐ 🔵 Work with vendor on remediation plan with timeline
Rollback Does Not Mean Failure: Position any pause as responsible implementation, not project failure. DSOs that rush failed deployments damage trust more than those that pause and correct.
5. Configuration & Integration (Weeks 2–3)
Practice Management System Integration
Dentrix Enterprise Integration
| Step | Action | Owner | Time | Notes |
|---|---|---|---|---|
| 1 | 🔵 Request API credentials from Henry Schein | Vendor + IT | 5-10 days | Submit early—this is often the longest lead time |
| 2 | Configure mConsent Dentrix connector | 🔵 Vendor | 2-4 hours | |
| 3 | Map appointment types and durations | Location Champion | 1-2 hours | |
| 4 | Map operatories and providers | Location Champion | 1 hour | |
| 5 | Test bi-directional sync in sandbox | IT + Vendor | 2 hours | |
| 6 | ⚠️ Validate patient matching logic | IT | 1 hour | Critical—mismatches create duplicate records |
| 7 | Test appointment creation, modification, cancellation | Champion | 1 hour | |
| 8 | Validate patient demographic sync | IT | 30 min |
Eaglesoft Integration
| Step | Action | Owner | Time | Notes |
|---|---|---|---|---|
| 1 | 🔵 Enable Eaglesoft API (Patterson support) | IT + Patterson | 3-5 days | |
| 2 | Configure mConsent Eaglesoft module | 🔵 Vendor | 2-4 hours | |
| 3 | Map provider schedules and appointment types | Champion | 1-2 hours | |
| 4 | Test schedule lookup and booking | IT + Vendor | 2 hours | |
| 5 | ⚠️ Configure operatory assignment rules | Champion | 1 hour | Complex multi-provider ops need careful setup |
| 6 | Validate insurance eligibility lookup | Champion | 30 min | |
| 7 | Test in parallel with live patients | Champion + Staff | 3 days |
Open Dental Integration
| Step | Action | Owner | Time | Notes |
|---|---|---|---|---|
| 1 | Generate API key in Open Dental | IT | 15 min | Customer Program link required |
| 2 | Provide API key to mConsent | 🔵 Vendor | 10 min | |
| 3 | 🔵 Configure Open Dental bridge | Vendor | 1-2 hours | Generally fastest integration |
| 4 | Map appointment types, providers, operatories | Champion | 1 hour | |
| 5 | Test bidirectional sync | IT + Champion | 1 hour | |
| 6 | Configure recall integration if using Open Dental recalls | Champion | 30 min |
Phone System Integration
VoIP Systems (RingCentral, 8x8, Vonage)
| Step | Action | Owner | Time |
|---|---|---|---|
| 1 | Document current call routing and IVR structure | IT | 1 hour |
| 2 | 🔵 Configure SIP trunk or call forwarding to mConsent | Vendor + IT | 2-4 hours |
| 3 | Set up number porting or forwarding rules | IT + Phone Vendor | 1-3 days |
| 4 | Configure after-hours routing | Champion | 30 min |
| 5 | Test inbound call handling end-to-end | Champion + Staff | 1 hour |
| 6 | ⚠️ Test failover if mConsent is unavailable | IT | 30 min |
Traditional Phone Systems
| Step | Action | Owner | Time |
|---|---|---|---|
| 1 | Assess analog-to-VoIP adapter requirements | IT | 1 hour |
| 2 | Order and install adapters if needed | IT | 1-2 weeks |
| 3 | Configure call forwarding at carrier level | IT + Carrier | 1-3 days |
| 4 | ⚠️ Test call quality and latency | Champion | 1 hour |
Test Environment Setup
Validation Checklist
☐ Appointment Scheduling
- New patient can schedule appointment via AI
- Existing patient recognized and matched correctly
- Appointment confirmation sent to patient
- Appointment appears correctly in PMS
- Appointment modification works
- Appointment cancellation works
- Recall scheduling works
☐ Patient Intake
- Digital forms sent to patient
- Completed forms populate PMS
- Insurance information captured correctly
- Medical history questions answered and stored
- ⚠️ HIPAA consent captured and documented
☐ Insurance Verification
- Eligibility lookup returns accurate data
- Coverage details match manual verification
- Failed lookups handled gracefully
☐ Call Handling
- Inbound calls answered within configured parameters
- Caller identified correctly (existing patient matching)
- Call transferred to human when appropriate
- After-hours calls handled per configuration
- Voicemail captured and transcribed
- ⚠️ Emergency calls routed immediately to human
☐ Reporting
- Call volume reports accurate
- Scheduling reports match PMS
- Staff can access reports appropriate to their role
Data Migration / Historical Data Ingestion
Patient Data Sync
☐ Determine if initial patient database sync is required ☐ 🔵 Coordinate bulk import with vendor ☐ ⚠️ Validate patient matching rules before bulk import ☐ Test recognition of existing patients after import ☐ Document any patients not matched (manual cleanup queue)
Appointment History
☐ Determine if historical appointments are needed (usually no) ☐ If yes, define lookback period (typically 6-12 months) ☐ 🔵 Coordinate historical import with vendor
Security and HIPAA Compliance
Enterprise-Level HIPAA Checklist
| Requirement | Status | Owner | Documentation |
|---|---|---|---|
| ☐ Business Associate Agreement (BAA) executed | Legal | Contract file | |
| ☐ Vendor SOC 2 Type II report reviewed | IT/Compliance | Audit file | |
| ☐ Data encryption at rest confirmed | 🔵 Vendor | Security attestation | |
| ☐ Data encryption in transit confirmed | 🔵 Vendor | Security attestation | |
| ☐ Access logging enabled | IT | Configuration | |
| ☐ Role-based access control configured | IT | Configuration | |
| ☐ Data retention policy documented | Compliance | Policy document | |
| ☐ Breach notification procedures confirmed | 🔵 Vendor + Legal | BAA + vendor documentation | |
| ☐ Patient consent workflows validated | Compliance | Intake form review | |
| ☐ ⚠️ Recording disclosure compliance confirmed | Legal | State-by-state review |
Recording Disclosure Requirements
⚠️ State laws vary on call recording consent. Ensure mConsent configuration includes appropriate disclosures based on location:
- One-party consent states: AI can record without explicit consent
- Two-party consent states (CA, FL, IL, MD, MA, MI, MT, NH, PA, WA): Must disclose recording to caller
☐ Compile list of locations by state consent requirement ☐ Configure mConsent disclosures accordingly ☐ 🔵 Confirm with vendor that disclosures are correctly implemented
Standardized vs. Location-Specific Configuration
Configuration Template: Standardize Centrally
| Setting | Standardized Configuration | Rationale |
|---|---|---|
| Greeting script | "Thank you for calling [Practice Name], how can I help you today?" | Brand consistency |
| Hours of operation format | 24-hour display, consistent format | Reporting consistency |
| Appointment duration defaults | Per procedure code | Clinical standardization |
| Emergency routing | Immediate transfer to human | Patient safety |
| No-show policy language | Standardized across DSO | Legal consistency |
| Insurance verification timing | 48 hours pre-appointment | Operational consistency |
| Confirmation messaging timing | 48 hours and 24 hours | Standardization |
Configuration Template: Allow Local Variation
| Setting | Local Discretion Allowed | Rationale |
|---|---|---|
| Practice name in greeting | Yes | Local branding |
| Provider availability | Yes | Varies by provider |
| Operatory assignment | Yes | Physical layout differs |
| Specialty appointment types | Yes | GP vs. specialty vs. pedo |
| After-hours handling | Limited (emergency protocol standardized) | Local on-call structures |
| Language preferences | Yes | Patient demographics vary |
Centralized vs. Per-Location Testing
Recommended Approach: Centralized Test Environment + Per-Location Validation
Centralized Test Environment:
- One sandbox instance connected to test PMS database
- Used for: integration validation, configuration templates, training
- Owner: Central IT
Per-Location Validation:
- 2-hour validation session per location before go-live
- Uses location's actual PMS data (test appointments, not real patients)
- Owner: Location Champion with IT support
6. Team Training Plan
Train-the-Trainer Model
Champion Selection Criteria
| Requirement | Why It Matters |
|---|---|
| Role: Office Manager or Senior Front Desk | They understand the workflow and have staff influence |
| Tech comfort: Above average | Must be comfortable navigating new software |
| Communication skills: Strong | Will be training peers and fielding questions |
| Tenure: 12+ months at location | Knows the practice, has relationships |
| Availability: Can commit 8-10 hours training + ongoing support role | Time investment is real |
| Attitude: Positive toward change | Resistance from champion is |
AI-generated implementation guide based on public vendor information. Verify specifics directly with Zaha AI / mConsent.