Arini — Implementation Playbook (DSO)

Arini AI Receptionist Implementation Playbook

For Dental Service Organizations (15–50 Locations)

---

1. Executive Summary

What Arini Does

Arini is an AI-powered receptionist platform that autonomously handles inbound and outbound patient phone calls, including appointment scheduling, rescheduling, confirmation, recall outreach, and general patient inquiries. The system integrates directly with practice management systems to access real-time scheduling availability and patient records, enabling 24/7 phone coverage without additional staffing.

Why DSOs Specifically Benefit from AI Receptionists

AI receptionists deliver compounding value at scale that single practices cannot achieve:

• Standardization at Scale: Ensure every patient call—across all 15–50 locations—receives identical, brand-consistent service. No more variability in phone etiquette, scheduling protocols, or missed opportunities between high-performing and struggling front desks.

• Data Aggregation & Visibility: Centralized call analytics expose patterns invisible at the location level: which offices have the highest abandonment rates, what times drive peak call volume across the portfolio, and where scheduling inefficiencies cost revenue.

• Labor Arbitrage: Front desk staffing is your largest variable cost at the location level. AI receptionists don't call in sick, don't require benefits, and don't create turnover costs averaging $3,500–$5,000 per replacement.

• Revenue Recapture: DSOs lose 15–30% of inbound calls to holds, voicemails, and after-hours timing. At $200–$400 average new patient value, a 50-location DSO leaving 10 calls per location per week unanswered bleeds $1.5M–$3M annually.

Expected Timeline: Decision to Full Deployment

Phase	Duration	Milestone
Pre-Implementation	Weeks 1–2	Infrastructure audit, baseline metrics captured
Pilot Wave (3–5 locations)	Weeks 3–6	Validate integration, refine scripts, measure impact
Wave 2 Expansion (8–12 locations)	Weeks 7–10	Scale with documented playbook
Wave 3 Expansion (remaining locations)	Weeks 11–16	Full deployment
Optimization & Stabilization	Weeks 17–20	ROI validation, workflow refinements

Total timeline: 16–20 weeks for a 30-location DSO, with high-performing organizations completing in 12–14 weeks.

---

2. Pre-Implementation Checklist (Weeks 1–2)

Technical Requirements

Hardware

☐ Confirm all locations have stable internet (minimum 25 Mbps download/5 Mbps upload per location) ☐ Verify phone system compatibility—Arini integrates via VoIP (RingCentral, Weave, 8x8, etc.) or direct carrier integration ☐ Document current phone tree/IVR structure at each location ☐ Identify locations still using analog/landline systems requiring VoIP migration

Software

☐ Inventory Practice Management System (PMS) versions across all locations ☐ Confirm PMS is on a supported version (Dentrix G7+, Eaglesoft 21+, Open Dental current stable release) ☐ Verify PMS cloud vs. server-based deployment at each location ☐ Document any middleware or third-party scheduling tools in use (LocalMed, NexHealth, etc.)

Network

☐ Validate firewall rules allow outbound HTTPS traffic to Arini endpoints ☐ Confirm no locations use restrictive proxy servers that block API calls ☐ Test latency to Arini servers from representative locations (<100ms acceptable)

Integrations Checklist

System	Required	Optional	Notes
PMS (scheduling read/write)	✅		Core functionality
Patient communication platform		✅	If using Weave, RevenueWell, etc.
Phone/VoIP system	✅		SIP trunk or API integration
CRM/Patient relationship tool		✅	For enhanced context

🔵 Vendor Onboarding Steps

Key Contacts to Establish

☐ Implementation Manager (your primary Arini contact through deployment) ☐ Technical Integration Specialist (for PMS/phone system integration) ☐ Customer Success Manager (post-launch relationship owner) ☐ Support escalation path (Tier 1 → Tier 2 → Engineering)

Onboarding Actions

☐ 🔵 Complete Arini enterprise onboarding form (organization details, location count, PMS inventory) ☐ 🔵 Schedule kickoff call with Arini implementation team (1 hour) ☐ 🔵 Execute Business Associate Agreement (BAA) with Arini ☐ 🔵 Obtain Arini's SOC 2 Type II report and security documentation ☐ Sign enterprise Master Services Agreement ☐ Establish dedicated Slack/Teams channel for implementation communication

Data/Access Prerequisites

Per Location

☐ PMS admin credentials (or create dedicated Arini service account) ☐ Phone system admin access for call routing configuration ☐ Current call tree/auto-attendant scripts (for replication/optimization) ☐ Business hours and scheduling rules documented

Centralized

☐ List of all locations with addresses, phone numbers, and NPI numbers ☐ Provider roster per location with scheduling parameters ☐ Standard appointment types and durations across organization ☐ Holiday schedule for the organization

Enterprise-Level Requirements

Network Standards

☐ 🟣 Decision: Centralized VoIP platform vs. location-managed phone systems

• Recommendation: Migrate to unified VoIP (RingCentral, 8x8, or Weave) if not already standardized—dramatically simplifies integration and reduces per-location configuration ☐ Document IP ranges and firewall rules that apply organization-wide ☐ Confirm SD-WAN or MPLS configuration if applicable

Hosting Architecture

☐ 🟣 Decision: Centralized API credentials vs. per-location credentials

• Recommendation: Centralized service account with location-level permissions—enables single pane of glass while maintaining data segregation ☐ Determine if Arini will connect to centralized PMS server (if using server-based PMS) or individual location databases

Identity & Access Management

☐ Confirm SSO provider (Okta, Azure AD, Google Workspace) ☐ 🔵 Verify Arini supports your SSO protocol (SAML 2.0 standard) ☐ Define role-based access control (RBAC) structure:

• Central Admin: Full access, configuration changes, all locations
• Regional Manager: View + limited config for assigned locations
• Location Manager: View + basic adjustments for single location
• Staff: Call logs and basic reporting only

Credentialing

☐ Create centralized Arini admin account structure ☐ Document password management approach (recommend credential vault like 1Password Business) ☐ Establish service account naming convention (e.g., arini-svc@yourdso.com)

Internal Stakeholder Alignment

Stakeholder Alignment Map

Stakeholder	Role in Implementation	Required Action	Timing
Board/Investors	Awareness, budget approval	🟣 Briefing on AI initiative, expected ROI, timeline	Week 1
CEO/COO	Executive sponsor, go/no-go authority	🟣 Approve vendor selection, budget allocation, rollout plan	Week 1
VP of Operations	Implementation owner	Own rollout execution, escalation decisions	Ongoing
Chief Dental Officer	Clinical sign-off	Approve call scripts, patient communication standards	Week 1–2
VP of IT/Technology	Technical approval	Validate security, integration architecture	Week 1
Regional Managers	Cascade communication, local oversight	Briefed on rollout plan, identify location champions	Week 2
Office Managers	Local implementation lead	Trained as champions, execute location-level tasks	Week 2–3
Front Desk Staff	End users	Change management, training	Week 3+
Providers	Awareness, scheduling preferences	Informed of changes, provide scheduling rules	Week 2

Approval Gates

☐ 🟣 Executive sponsor formally assigned (recommend COO or VP Ops) ☐ 🟣 Budget approved for implementation + Year 1 subscription ☐ 🟣 Legal/compliance sign-off on BAA and data handling ☐ 🟣 IT security approval of Arini's architecture ☐ CDO approval of patient-facing call scripts

⚠️ Baseline Metrics to Capture BEFORE Go-Live

Critical: Without baseline data, you cannot prove ROI. Capture these metrics for every location during Weeks 1–2.

Phone Performance Metrics

Metric	How to Capture	Target Format
Total inbound calls per week	Phone system reports	Number per location
Call answer rate	Phone system reports	Percentage
Average hold time	Phone system reports	Seconds
Abandoned call rate	Phone system reports	Percentage
After-hours calls (missed)	Phone system or voicemail count	Number per week

Scheduling Metrics

Metric	How to Capture	Target Format
New patient appointments scheduled per week	PMS report	Number per location
Appointment fill rate	PMS schedule analysis	Percentage of available slots filled
Same-day/next-day scheduling rate	PMS report	Percentage of appointments
No-show rate	PMS report	Percentage
Recall reactivation rate (if doing outbound)	PMS hygiene recall report	Percentage

Operational Metrics

Metric	How to Capture	Target Format
Front desk FTE count	HR/payroll data	Number per location
Front desk overtime hours	Payroll data	Hours per week
Average cost per front desk FTE (fully loaded)	Finance team	Annual cost
Staff turnover rate (front desk)	HR data	Annual percentage

Revenue Metrics

Metric	How to Capture	Target Format
Average new patient first-visit revenue	PMS/financial reports	Dollar amount
Monthly production per location	Financial reports	Dollar amount
Recall revenue per month	PMS production reports	Dollar amount

⚠️ Common Failure Point: Many DSOs have inconsistent reporting across locations. If your PMS reports aren't standardized, invest 3–5 days in Week 1 to build a uniform extraction template. The ROI calculation depends entirely on this baseline.

Standardizing Baseline Measurement

☐ Create a standardized Excel/Google Sheet template for all metrics ☐ Define exact date ranges for baseline period (recommend: 4 most recent complete weeks) ☐ Assign one person to compile baseline for all locations (ensures consistency) ☐ 🟣 Review and sign off on baseline data accuracy before proceeding ☐ Store baseline in shared location accessible to implementation team and leadership

Template Format Example:

Location	Inbound Calls/Week	Answer Rate	Abandoned Rate	Hold Time (sec)	New Pts Scheduled/Week	Fill Rate
Location A	245	78%	12%	45	8	82%
Location B	312	65%	22%	78	6	71%
...	...	...	...	...	...	...

---

3. Location Readiness Assessment

Scoring Framework

Rate each location on the following factors using a 1–5 scale. This framework identifies your optimal pilot locations and informs your wave structure.

Factor 1: IT Infrastructure Maturity

Score	Criteria
5	Modern VoIP phone system, PMS on current version, reliable high-speed internet (50+ Mbps), server/workstations <3 years old
4	VoIP phone system, PMS within 1 version of current, stable internet (25–50 Mbps), hardware 3–5 years old
3	Mixed phone system (VoIP + some analog), PMS 2 versions behind, occasional connectivity issues, hardware 5–7 years old
2	Primarily analog phones, outdated PMS version, frequent connectivity issues, aging hardware
1	Analog phone system, PMS unsupported version, unreliable internet, hardware failures common

Factor 2: Staff Tenure and Adaptability

Score	Criteria
5	Average tenure >3 years, <15% annual turnover, history of successful tech adoptions, staff express enthusiasm for efficiency tools
4	Average tenure 2–3 years, 15–25% turnover, generally receptive to change, completed previous tech rollouts without major issues
3	Average tenure 1–2 years, 25–35% turnover, mixed reaction to change, some past tech rollouts had challenges
2	Average tenure <1 year, 35–50% turnover, resistance to change documented, tech implementations historically difficult
1	High turnover (>50%), active resistance to change, failed tech implementations, significant retraining required

Factor 3: Patient Volume

Score	Interpretation	Risk/Reward
5	Very high volume (>300 calls/week)	Highest ROI potential, but highest risk if issues occur
4	High volume (200–300 calls/week)	Strong ROI, manageable complexity
3	Moderate volume (100–200 calls/week)	Good pilot candidate—meaningful data without overwhelming risk
2	Lower volume (50–100 calls/week)	Lower immediate ROI, but safer for learning
1	Low volume (<50 calls/week)	Limited ROI impact, not ideal for pilot

Note: For Wave 1 pilots, volume scores of 3–4 are ideal. A score of 5 should be avoided for initial pilots due to risk exposure.

Factor 4: Existing Tech Stack Compatibility

Score	Criteria
5	PMS with documented Arini integration (Dentrix, Eaglesoft, Open Dental), VoIP system on Arini's supported list, no conflicting middleware
4	Supported PMS, VoIP needs minor configuration, minimal conflicting systems
3	Supported PMS but older version requiring update, phone system needs VoIP migration, some middleware complications
2	PMS on edge of support, significant phone system changes required, multiple conflicting systems
1	Unsupported or heavily customized PMS, analog phones requiring full replacement, complex legacy systems

Factor 5: Local Champion Availability

Score	Criteria
5	Office manager is tech-forward, expresses enthusiasm, has bandwidth, proven track record leading initiatives
4	Office manager is supportive, has capacity, willing to own the rollout locally
3	Office manager is neutral but compliant, may need extra support, limited but available bandwidth
2	Office manager is skeptical or overwhelmed, no clear alternative champion available
1	Office manager opposed or absent, no viable local champion, change leadership vacuum

Composite Scoring & Rollout Sequencing

Calculating Composite Score

For each location, calculate:

Composite Score = (IT × 1.0) + (Staff × 1.2) + (Volume × 0.8) + (Tech Stack × 1.0) + (Champion × 1.5)

Weightings reflect implementation reality:

• Champion availability (×1.5): Most predictive of success
• Staff adaptability (×1.2): Second most critical
• Volume (×0.8): Lower weight because high volume increases risk for pilots

Maximum possible score: 27.5

Score Interpretation

Score Range	Readiness Level	Rollout Recommendation
22–27.5	High readiness	Wave 1 candidate
17–21.9	Moderate-high readiness	Wave 2
12–16.9	Moderate readiness	Wave 3
7–11.9	Low readiness	Wave 4 / Remediation required
<7	Not ready	Address infrastructure/staffing before including

Sample Assessment Output

Location	IT	Staff	Volume	Tech Stack	Champion	Composite	Wave
Scottsdale Main	5	4	3	5	5	24.9	1
Mesa East	4	5	4	4	5	25.5	1
Phoenix Central	4	3	5	4	4	22.6	1
Tempe	4	4	4	4	3	21.3	2
Glendale	3	3	3	3	4	18.0	2
Gilbert	2	2	4	3	2	14.6	3
Chandler	2	2	2	2	2	11.0	Remediate

Additional Selection Criteria for Wave 1

Beyond composite scores, Wave 1 locations should also meet these criteria:

☐ Geographic distribution: If possible, include locations from different regions to test regional manager involvement ☐ Specialty representation: Include at least one GP-only and one specialty or multi-specialty location if applicable ☐ PMS diversity: If you have multiple PMS platforms, include at least one of each in Wave 1 ☐ Avoid problem locations: Do not include locations currently undergoing other major transitions (new office manager, relocation, renovation)

---

4. Rollout Strategy

Recommended Wave Structure

For a 30-location DSO (adjust proportionally for your size):

Wave	Locations	Duration	Purpose
Wave 1 (Pilot)	3–5 locations	4 weeks	Validate integration, refine scripts, identify issues, build internal case study
Wave 2	8–12 locations	3 weeks	Scale with proven playbook, test train-the-trainer model
Wave 3	Remaining locations	4–6 weeks	Full deployment leveraging documented processes

Wave Timeline Overview

Week 1–2:  Pre-implementation (all locations simultaneously)
Week 3–6:  Wave 1 Pilot (3–5 locations)
Week 7:    Wave 1 evaluation, go/no-go decision
Week 8–10: Wave 2 deployment (8–12 locations)  
Week 11:   Wave 2 evaluation, go/no-go decision
Week 12–17: Wave 3 deployment (remaining locations)
Week 18–20: Optimization & stabilization

Wave 1 Pilot Selection Criteria

Select 3–5 locations that meet ALL of the following:

☐ Composite readiness score ≥22 ☐ Strong local champion confirmed and committed ☐ PMS is on current supported version ☐ VoIP phone system already in place (no migration required) ☐ Regional manager is engaged and supportive ☐ No major competing initiatives in progress ☐ Call volume sufficient to generate meaningful data (100–250 calls/week ideal) ☐ Representative of broader portfolio (not outliers in patient demographics or specialty mix)

Anti-criteria (avoid these for Wave 1):

• Flagship/highest-revenue location (too much risk)
• Newest acquisition (still integrating)
• Locations with active office manager transitions
• Highest-volume locations (250+ calls/week)

🟣 Go/No-Go Criteria

Advancing from Wave 1 to Wave 2

Hard Requirements (all must be met): ☐ Integration stable for 5+ consecutive business days with no unplanned downtime ☐ ≥85% of scheduled calls handled successfully by Arini ☐ Zero HIPAA or patient safety incidents ☐ PMS data synchronization accurate (scheduling conflicts <2%) ☐ All pilot location champions report "ready to proceed"

Target Metrics (majority should be met): ☐ Patient satisfaction score maintained or improved vs. baseline ☐ Call answer rate improved or maintained vs. baseline ☐ Staff feedback net positive (>60% favorable) ☐ New patient scheduling rate maintained or improved

Advancing from Wave 2 to Wave 3

Hard Requirements: ☐ All Wave 1 criteria still met ☐ Train-the-trainer model validated (champions successfully trained their teams) ☐ Escalation process tested and effective ☐ No integration issues requiring vendor engineering intervention in past 10 days

Target Metrics: ☐ Aggregate phone performance improved across Wave 1+2 locations ☐ Champion capacity confirmed for Wave 3 support

⚠️ Rollback Plan

If a wave fails to meet go/no-go criteria:

Immediate Actions (Within 24 hours)

1. Halt current wave expansion — no new locations go live
2. Revert failing locations to pre-Arini phone routing (document routing reversion steps during implementation)
3. Convene incident review: VP Ops + IT + Arini implementation team
4. Communicate status to regional managers with clear holding message

Assessment Period (48–72 hours)

1. Root cause analysis: Integration issue vs. process issue vs. training gap
2. Arini provides written remediation plan with timeline
3. Determine if issue is systemic (affects all locations) or localized

Decision Framework

Issue Type	Response	Timeline
Integration bug affecting all locations	Full pause, Arini resolves, re-test from Wave 1 subset	1–2 weeks
Integration bug affecting specific PMS version	Pause affected locations, continue others	3–5 days
Training/process gap	Pause Wave, intensive training intervention	1 week
Isolated location issue (champion, staff, infrastructure)	Remove location from current wave, continue others	Immediate

Communication Protocol During Rollback

• Regional managers: Daily updates until resolution
• Location staff at affected sites: "We're pausing to optimize" — avoid alarm
• C-suite: Daily status until resolution, weekly after stabilization
• Board: Only if pause exceeds 2 weeks or involves significant incidents

---

5. Configuration & Integration (Weeks 2–3)

Step-by-Step PMS Integration

Dentrix Integration

Estimated Time: 2–4 hours per location (can be parallelized)

☐ 🔵 Arini provides Dentrix integration documentation and credentials ☐ Verify Dentrix version (G7 or later required) ☐ Create dedicated Arini service user in Dentrix with following permissions:

• Appointment Book: View, Create, Modify
• Patient Records: View (no modify)
• Schedule Templates: View ☐ Enable Dentrix API access (Office Manager → Preferences → Integrations) ☐ 🔵 Provide Arini with:
• Server IP/hostname (if on-premise) or Dentrix Cloud credentials
• Service user credentials
• Location identifier/practice ID ☐ ⚠️ Configure Dentrix operatory mapping (Arini must understand which operatories accept which appointment types) ☐ Map appointment types and durations to Arini scheduling rules ☐ Test: Create test appointment via Arini, verify appears in Dentrix ☐ Test: Modify existing appointment via Arini, verify change reflects ☐ Test: Verify patient lookup returns correct records

Eaglesoft Integration

Estimated Time: 2–3 hours per location

☐ 🔵 Arini provides Eaglesoft integration module installation file ☐ Verify Eaglesoft version (21.00 or later recommended) ☐ Install Arini integration module on Eaglesoft server ☐ Create Eaglesoft user for Arini with scheduling permissions ☐ 🔵 Configure Arini with Eaglesoft database connection details ☐ Map provider schedules and appointment types ☐ ⚠️ Configure time zone handling (Eaglesoft and Arini must match) ☐ Run integration validation tests

Open Dental Integration

Estimated Time: 1–2 hours per location

☐ Verify Open Dental version (current stable release) ☐ Enable API module in Open Dental (Setup → Program Links → API) ☐ Generate API key with scheduling permissions ☐ 🔵 Provide Arini with:

• Open Dental API endpoint URL
• API key
• Clinic ID (if multi-location Open Dental instance) ☐ Map appointment types and operatories ☐ Run integration tests

Phone System Integration

VoIP Platform Integration (RingCentral, 8x8, Weave, etc.)

Estimated Time: 1–2 hours per location

☐ Document current call routing/IVR structure ☐ 🔵 Arini provides SIP trunk details or API credentials for your platform ☐ Configure call forwarding rules:

• Option A: All calls route to Arini first, Arini transfers as needed
• Option B: IVR presents choice, certain options route to Arini ☐ 🟣 Decision: Full replacement vs. IVR handoff
• Recommendation for Wave 1: Start with IVR handoff ("Press 1 to schedule an appointment") to limit scope
• Scale to full replacement in Wave 2+ after validation ☐ Configure failover routing (if Arini unavailable, calls route to front desk) ☐ Test inbound call routing end-to-end ☐ Test call transfer back to front desk ☐ Test voicemail handoff for after-hours (if applicable)

Test Environment Setup

Recommended Approach for DSOs

🟣 Decision: Centralized test environment vs. per-location testing

Approach	Pros	Cons	Recommendation
Centralized test environment	Single place for validation, controlled	May not catch location-specific issues	Use for initial configuration
Per-location testing	Catches real-world issues	Time-intensive, coordination complex	Required before each location goes live

Recommended: Centralized test environment for configuration development → Per-location validation before go-live

Centralized Test Environment Setup

☐ Create test instance of PMS (or use sandbox if cloud-based) ☐ 🔵 Arini provisions test environment connected to test PMS ☐ Configure with representative data (anonymized if production data) ☐ Establish test phone number that routes to test Arini instance ☐ Document test scenarios (see Validation Checklist below)

Per-Location Validation Checklist

Run these tests at each location before go-live:

Test	Expected Result	Pass/Fail
Call Arini number, request new patient appointment	Appointment created in PMS with correct details	☐
Call to reschedule existing appointment	Appointment moved in PMS	☐
Call to cancel appointment	Appointment cancelled/noted in PMS	☐
Request appointment outside available hours	Arini correctly identifies unavailability	☐
Request appointment with specific provider	Correct provider's schedule checked	☐
Ask about insurance acceptance	Correct response per location config	☐
Request to speak with a person	Call transfers to front desk successfully	☐
After-hours call	Correct after-hours handling (voicemail, callback request)	☐
Spanish language request (if applicable)	Correct language handling	☐
⚠️ Edge case: Caller provides wrong phone number	Arini handles gracefully, doesn't create duplicate patient	☐

Data Migration/Historical Data Ingestion

What Arini Needs

☐ Historical patient contact information (for outbound recall calling) ☐ Outstanding recall list (patients due/overdue for hygiene) ☐ Outstanding treatment plans (if using for treatment follow-up calls)

Migration Steps

☐ Export recall list from PMS (standard report format) ☐ 🔵 Arini provides data format template ☐ Format export to match Arini requirements ☐ 🔵 Arini ingests historical data ☐ Verify record count matches source ☐ ⚠️ Test outbound call to sample records to verify data accuracy

Security and HIPAA Compliance Verification

Enterprise HIPAA Checklist

Requirement	Status	Evidence
☐ BAA executed with Arini		Signed agreement on file
☐ Arini SOC 2 Type II report reviewed		Report dated within 12 months
☐ Data encryption in transit (TLS 1.2+)		Arini security documentation
☐ Data encryption at rest (AES-256)		Arini security documentation
☐ PHI access logging enabled		Arini admin console
☐ Call recordings stored compliantly		Storage location, retention policy
☐ Data retention policy documented		Aligned with your retention requirements
☐ Incident response plan reviewed		Arini's IR procedures
☐ Access controls configured per RBAC		Admin console verification
☐ SSO integration configured		Users authenticate via your IDP
☐ Minimum necessary access enforced		Service accounts have limited permissions

Data Governance

☐ 🟣 Decision: Call recording retention period

• Options: 30 days / 90 days / 1 year / 7 years
• Recommendation: 90 days standard, 7 years if state law requires longer ☐ 🟣 Decision: Call recording storage location
• Arini cloud storage vs. export to your storage
• Recommendation: Arini cloud storage with export capability for legal holds ☐ Document data flow: Patient call → Arini → PMS → Your analytics systems ☐ Verify patient consent language covers AI interaction (state-specific requirements vary)

Configuration Templates

Standardized Configuration (Identical Across All Locations)

Setting	Standardized Value	Rationale
Brand greeting	"[DSO Name], this is [Assistant Name], how can I help you?"	Brand consistency
Hold music/messaging	Centralized marketing-approved audio	Brand consistency
Call transfer phrases	Standardized language	Training consistency
HIPAA verification steps	Standard identity verification questions	Compliance
Escalation triggers	Same scenarios trigger transfer to human	Predictable behavior
Language support	Enabled/disabled same across portfolio	Consistent patient experience
Quality assurance sampling rate	Same % across locations	Fair comparison

Location-Specific Configuration (Varies)

Setting	Allow Variation	Example Variation
Business hours	Yes	Location A: M-F 8-5, Location B: M-Th 7-7, F 7-3
Provider roster	Yes	Different providers per location
Appointment types offered	Yes	Specialty locations have different procedure types
Insurance plans accepted	Yes	Vary by location contracts
Specific provider scheduling rules	Yes	Dr. Smith: no new patients after 4pm
Spanish language support	Yes	Based on local patient demographics
Operatory assignments	Yes	Physical layout differs
Emergency