The system-of-record split.

The integration question almost everyone asks first is "does Voze sync with my DMS?" — and the answer is yes, but it's the wrong question. The right one is: which system owns which kind of record? Because if you don't agree on that before you wire anything up, the integration will fight you forever.

Voze's posture is simple. Your DMS is the system of record for the transaction: who's an account, who bought what, when, for how much, on which terms. Your CRM (if you have one) is the system of record for the structured pipeline: open opportunities, forecast calls, contract values. Voze is the system of record for the conversation: what was said, by whom, at which account, with which competitor mentioned and which follow-up promised.

That framing matters because it tells you what NOT to sync. Voze isn't trying to replace your DMS account list — it reads from it. Voze isn't trying to own pricing or invoices — those stay where they are. What Voze owns is the field signal: the voice note, the structured tags pulled out of it, the flags surfaced by the action layer. Everything else is reference data.

Three integration patterns.

Across all the DMS and ERP platforms we work with, the integration falls into one of three patterns. Knowing which one fits your setup tells you 80% of what the project looks like before you read a single platform-specific page.

Pattern A — Native API integration.

Your DMS has a modern REST or SOAP API with documented endpoints for accounts, contacts, parts, and orders. Voze reads from those endpoints on a schedule (typically 15–60 minutes) to keep its account list in sync, and writes back signal records to a custom field or notes endpoint. Lowest friction. Typical setup: 2–3 weeks including UAT. Examples: HubSpot, Salesforce, NetSuite, modern Karmak deployments.

Pattern B — Mid-tier integration via a sync layer.

Your DMS has APIs but they're partial, brittle, or built for batch. We use a middleware layer (often the customer's existing iPaaS — Workato, Boomi, Zapier — or our own sync service) to map fields and handle the impedance mismatch. Typical setup: 4–6 weeks. Examples: older Karmak versions, CDK Truck Series, Procede Excede (with the appropriate access tier).

Pattern C — Flat-file or scheduled export.

Your DMS doesn't expose useful APIs to third parties, or it does but the cost is prohibitive. We work from a scheduled export — typically nightly CSV or fixed-width file — that we ingest to keep the account directory current. Voze can still surface signals; what gets harder is pushing structured data back into the DMS. Typical setup: 3–5 weeks, plus whatever it takes to stand up the export. Examples: some MaddenCo deployments, Reynolds & Reynolds, legacy ERP deployments with no API surface.

Platform-by-platform notes.

What follows is short-form on each platform — enough for an IT lead to know which pattern applies and what the gotchas are. We'll send the full integration brief for your specific setup during the technical review.

MaddenCo.

Common in the independent tire dealer world. Most deployments fall into Pattern B or C — the API surface is real but not uniformly modern. The integration sync is typically scheduled rather than real-time, but for field intelligence that's fine: rep notes don't need to land in the DMS in seconds, they need to land before the next visit. Customer story: see Bauer Built.

Karmak Fusion.

Dominant in heavy-duty truck dealer DMS. Newer Karmak Fusion installations support Pattern A; older deployments typically Pattern B. Voze maps to Karmak's account and parts hierarchy directly, and signal records land on the customer record as notes or in a custom field, depending on how your Karmak instance is configured. Customer story: see McCandless Truck Center.

CDK Global Heavy Truck (Truck Series).

Pattern B is typical. CDK's API access tiers determine what's possible — we'll need to know your tier early in scoping. The DealerStar pattern (where it applies) is well-trodden; the integration ends up being more about navigating the entitlement layer than the technical work.

Procede Excede.

Strong API surface; usually Pattern A or B. Procede's been forward-leaning on third-party integrations, so the technical work is usually clean. The gotcha is data hygiene — Excede tends to accumulate duplicate account records over time, and the cleanup before sync is often the longest pole.

Reynolds & Reynolds (ERA-IGNITE).

Pattern C is most common given Reynolds' historical posture on third-party data access. We work from scheduled exports and surface signals in Voze without writing back to the DMS, which is acceptable for most field-intelligence use cases. If you have ERA Open Track or equivalent extended access, we can do Pattern B.

NetSuite (ERP, not DMS).

Pattern A. NetSuite's SuiteTalk REST API is mature; the integration is straightforward. We typically map Voze accounts to NetSuite customer records and write signal records to a custom record type. Useful for distributors who run NetSuite as their book-of-record rather than (or alongside) a vertical DMS.

Data flow: what goes which way.

Specifically, in either direction:

From your DMS into Voze.

• Account directory. Customer/account records, addresses, hierarchy (parent/child where applicable). Refresh: daily or near-real-time depending on integration pattern.
• Contact records. Buyer-side contacts known at each account. Used to disambiguate names in voice notes ("Sam at Acme" → which Sam).
• Product / part records. Your SKUs, descriptions, categories. Used to tag products mentioned in voice notes against the records they correspond to.
• Revenue trend (optional). Last-90-day account spend, used by Voze's at-risk view to cross-reference signal patterns against transaction patterns.

From Voze into your DMS.

• Voice notes (transcription). Written to the account record as a note or activity. Most customers leave the audio in Voze and push the transcript.
• Structured tags. Competitor mentions, product mentions, follow-up dates — written to custom fields or activity records depending on what your DMS supports.
• Action flags. Urgent/Action/Watch flags pushed to a flag field on the customer record, so reps can see them when they open the account in the DMS even if they're not in Voze that moment.

The data that does NOT move between systems: pricing, invoicing, contracts, inventory, anything financial. Voze is a conversation layer. Your DMS handles the transaction layer. Keeping the boundary clean keeps the integration simple and keeps audit trails clean.

What IT actually has to do.

The work most IT teams have to do for a Voze rollout is smaller than they expect. The full list, in order:

1. Confirm your DMS vendor and version. Especially version — most integration risk lives in version differences, not vendor differences.
2. Confirm your API access tier. Some DMS vendors gate features behind extended-access SKUs. We need to know what you have before scoping.
3. Provision read-only credentials. For initial sync. We expand to write access only after UAT and only for the specific endpoints we'll write to.
4. Stand up the export, if applicable. For Pattern C deployments, you'll need to configure a recurring export. The Voze team will give you the exact spec.
5. SSO configuration. Voze supports SAML 2.0 SSO via Okta, Azure AD, OneLogin, Google Workspace. Setup is typically 30–60 minutes.
6. UAT. Two to three week cycle where Voze pulls a sandbox of your data, you verify the matching logic is correct, we tune.
7. Pilot rollout. Three to five reps for 90 days against the live integration. See the 90-day pilot guide for the full pilot shape.

Security, ownership, and exit.

Three things every RevOps and IT lead should pin down before signing.

Security.

Voze runs SOC 2 controls, SSO via your IdP, data residency in the US, and role-based access at the account, territory, and rep level. Voice notes and transcripts are encrypted in transit and at rest. The full security packet (controls, sub-processors, incident-response process) is part of the technical review and we don't ask you to fill out a security questionnaire blind.

Data ownership.

Your voice notes, transcripts, accounts, contacts, signals, and patterns are your data — not Voze's. Contractually, we don't train models for other customers on your data. You can export everything in CSV or via API any time, and we don't have lock-in clauses on the export path.

Exit.

If you ever wind down Voze, the question that matters is: what stays in your DMS? Because the signal records we push into your DMS are written to your DMS's records, they don't disappear when Voze does. The audio and the transcripts in Voze come out via export. Your DMS keeps the customer records and the notes that were written to them. Clean exit, no orphaned data.