VProGo

Getting your facility ready…

Architecture transparency

When You Sign Alleva, You Also Sign the Stack Underneath.

Alleva's CRM module is built on Dazos technology. That makes Alleva a multi-vendor stack presented as a single product — which has implications for contract terms, support coordination, and data portability. This page lays out the architecture honestly and shows the single-vendor alternative.

The Two Stacks, Layer by Layer

Five operational layers, two ways to assemble them. Single-vendor or stacked.

Alleva: Stacked Architecture

EMR / Clinical

Layer 1

Alleva (own platform)

Documentation, group notes, treatment plans, compliance.

CRM / Admissions

Layer 2

Dazos (white-labeled / OEM)

Underlying CRM technology and architecture provided by Dazos. Transitive contract exposure to Dazos terms applies.

RCM / Billing

Layer 3

Third-party billing partners

Typically delivered through external billing companies.

Patient Engagement

Layer 4

Not native

Generally requires third-party tooling.

Marketing / SEO

Layer 5

Not native

Out of scope; facility hires agency or in-house team.

VProGo: Single-Vendor Stack

EMR / Clinical

Layer 1

Your existing EMR (Kipu live; Sunwave + Alleva in development)

VProGo integrates with your EMR; clinical workflow stays where your team already is.

CRM / Admissions

Layer 2

VProGo native

Multidirectional referral lifecycle, working referrals Kanban, 8-tier payment prediction. Single MSA.

RCM / Billing

Layer 3

VProGo native + VProBilling channel

Full RCM with ClaimMD clearinghouse (Waystar in dev), or run through a VProBilling-partnered billing company.

Patient Engagement

Layer 4

VProMove native

PWA for peri-treatment + alumni. AI SI detection, gamification, two-way messaging.

Marketing / SEO

Layer 5

VProSEO native

5-dimension scorecard with CRM Bridge data integration. No separate agency or tool stack required.

What "Stacked" Means in Practice

Multi-vendor architecture has legitimate use cases. It also has costs that show up in places facility operators don't always look during procurement.

Transitive contract exposure

When Alleva's CRM is powered by Dazos, the terms of the underlying Dazos relationship can apply to your CRM-layer use even though you signed an Alleva agreement. Constructive-termination clauses, asymmetric liability caps, and unilateral-modification rights in the underlying stack are not eliminated by the Alleva wrapper.

Multi-vendor blast radius

A bug at the CRM layer requires coordination between Alleva (the vendor you signed with) and Dazos (the vendor providing the technology). Issue-resolution timelines extend. Contract-renegotiation requires conversations with multiple counterparties.

Data-portability complexity

On exit, your data lives across at least two vendor systems. CRM-layer data sits with Dazos' infrastructure even though your relationship is with Alleva. Self-service export is harder when the vendor that owns the export doesn't own the data store.

Pricing-model opacity

Stacked-vendor architectures make pricing harder to interrogate. Some Alleva pricing flows through Alleva; some flows through underlying-vendor add-ons. Total-cost-of-ownership requires building from multiple contracts rather than reading one rate card.

Capability + Contract Comparison

Notes call out where the stacked-architecture pattern affects each comparison row.

Capability / TermVProGoAlleva
Single-vendor accountability
Alleva users coordinate across multiple vendor relationships
Native multidirectional referral lifecycle
Forward-only pipeline pattern (Dazos-derived)
Working referrals (admissions Kanban)
8-tier payment prediction engine
Native full RCM with clearinghouse
Alleva typically routes billing to external partners
Billing company portal (multi-facility BC channel)
Native patient engagement PWA
Alumni AI SI detection
VProSEO marketing intelligence layer
Single MSA covering full operational stack
Alleva, Dazos, billing partner = three contracts minimum
Multi-clearinghouse abstraction
Native Kipu EMR integration
Mutual 12-month liability cap
Depends on which underlying contract applies
No constructive-termination clause
Dazos' constructive-termination clause flows through to CRM-layer use
$0 self-service data export
Multi-vendor exports require coordination

Common Questions

How public is the Alleva-runs-on-Dazos relationship?

Alleva publicly markets its CRM module; the technology underneath has historically been provided by Dazos. The exact commercial structure (white-label, OEM, partnership, etc.) varies and is not always disclosed in customer-facing materials. The practical question for facility operators is what contracts they're signing and what contracts the platform they're running depends on. That's a question worth asking Alleva directly during procurement, and worth asking your counsel to verify.

Why does it matter to me if Alleva runs on Dazos?

Three reasons. First, contract exposure: the terms of the underlying Dazos relationship can flow through to your CRM-layer use, including the clauses that have made the Dazos agreement controversial — see the VProGo vs Dazos comparison page. Second, vendor-lock complexity: changing CRMs is harder when your CRM provider doesn't own the underlying tech. Third, pricing opacity: you're paying through one vendor for technology owned by another, which makes negotiation and renewal less transparent than a single-vendor relationship.

Is single-vendor architecture really better?

Not always. Best-of-breed multi-vendor stacks have legitimate strengths — specialization, flexibility, less single-vendor risk. The trade-off shows up in coordination cost: more contracts, more support relationships, more migration complexity. For behavioral health facilities specifically, the multi-vendor coordination cost is high because admissions workflow spans CRM, EMR, billing, and patient engagement — and those vendors typically don't share data well. VProGo's single-vendor stack collapses the coordination cost. Whether that's worth more than best-of-breed flexibility depends on facility size, IT capacity, and how much coordination tax you're currently paying.

Does VProGo replace Alleva entirely?

It depends on how you're using Alleva today. If Alleva is primarily your EMR and CRM, VProGo can replace the CRM layer while you keep Alleva for clinical (Alleva integration is in development). If you want to move off Alleva entirely, VProGo provides CRM, RCM, patient engagement, and marketing natively, and integrates with your next EMR. The transition can be sequenced — VProGo first as the operations layer, EMR change later if you want to.

What about the Hello Alleva rebrand?

Alleva has used variations of its branding ("Hello Alleva," "Alleva," etc.) over time. The underlying platform and the underlying CRM technology relationship are the same regardless of brand presentation. This page uses "Alleva" generically to refer to the platform.

How does VProGo handle the contracts?

One MSA, one Order Form, one Business Associate Agreement, one accountable party. The full MSA is published in summary form in /compare/vprogo-vs-dazos and available in full on request. Key terms: Year 1 month-to-month, mutual 12-month liability cap, $0 self-service data export, signed amendments required for any change to the BAA or SLA, mutual 12-month non-solicit at actual damages only. No transitive vendor exposure because there is no underlying vendor.

One Stack. One Contract. One Accountable Party.

See the platform end-to-end and ask any architecture question you want during the demo.

Ready to Simplify Your Operations?

Contact us to schedule a demo and see VProGo in action.