How do you verify a dealership software integration?

Get matching statements

Ask both vendors and any data intermediary to confirm the same scope in writing. Resolve differences about availability, write-back, timing and fees before the order form is signed.

Test representative records

Use normal and exception cases: duplicates, changed ownership, opt-outs, failed transactions, deleted records and delayed updates. Reconcile source and destination results.

Define operational ownership

Document alerts, logs, severity levels, escalation contacts, remediation, replay of missed data and responsibility when either product changes.

Start from the record, not the logo

A logo on a partner page tells you two companies have some relationship. It does not tell you which products, which versions, which dealerships, which data or which direction.

Write the integration down as a record with those fields, then ask each vendor to confirm it in writing. Where the two statements differ, the difference is the finding, and it is far cheaper to learn it before signing than during implementation.

A representative test plan

Pick one lead, one customer with a duplicate, one deal and one service visit. Move each through both systems, then change a field on each side and watch what happens.

Repeat with an opt-out, a reassignment and a deleted record. Record what arrived, when and in what form, and keep the screenshots.

The same plan can be re-run after any product release, which is the moment integrations most often change.

Common mistakes when verifying

Accepting a demonstration in a vendor sandbox is the first, because it proves the sandbox works. Second is not asking who owns support when both vendors blame each other.

Third is ignoring fees: setup, monthly and per-transaction charges can be billed to either side. Finally, forgetting to schedule re-verification means a record that was correct at signing quietly drifts as products change.

What to file after verification

Keep a one-page record for each integration: the products and versions, the systems and dealerships covered, the objects and directions, the frequency, the fee and who pays it, the owner on each side, the test date and results and the next review date. When something changes, the record is the starting point for the conversation with both vendors.

Who should be involved

Involve the department that uses the data, the person who owns the system of record, and someone who can read the contract. Each will notice different problems.

The department knows what breaks the workflow, the system owner knows the data rules and the contract reader knows the fee and support terms. A verification done by one role alone tends to miss one of these.