BDC Vendor Onboarding: Build the Access Plan First

Use this BDC vendor onboarding checklist to define CRM access, ownership, security, escalation, and offboarding before launch.

BDC vendor onboarding should begin with a written access plan, not a shared password and a promise to clean things up later. The plan names the systems the partner can use, the customer information required for the work, the people who own approvals, and the steps that remove access when the relationship changes.

This is an operating checklist, not legal advice. The dealership's legal, compliance, and information security teams should decide which rules apply. The BDC team still needs a document it can follow on launch day.

Quick answer

Before the first lead moves, define five things:

The hard part is not creating another policy binder. It is turning policy into specific CRM roles, queue rules, and owner names.

Why broad access is the wrong shortcut

Launch dates create pressure. The CRM role is not ready, the telephony integration still needs testing, and someone suggests giving the outside team the same permissions as an internal manager. It works quickly. It also makes the exception permanent unless someone remembers to revisit it.

A BDC agent may need assigned leads, customer notes, tasks, appointment fields, and approved communication tools. That does not automatically require user administration, unrestricted exports, accounting data, finance records, or every store's customer history.

Start with the work. For each workflow, write down the record types the agent must see, the fields the agent may change, and the actions the agent may take. Then build the role around that list. If a permission does not support a named task, leave it out until the owner approves a documented reason.

The FTC's June 2025 Safeguards Rule guidance for automobile dealers says covered dealers must develop, maintain, and update a written information security program. It lists access controls, multifactor authentication, encryption, logging, service provider oversight, and incident response among the program elements. The guidance is a useful floor for the onboarding conversation, even though the dealership must determine its own obligations with counsel.

Map the systems before assigning users

A launch can touch more systems than the project plan suggests. The CRM is obvious. Call routing, recording storage, texting, email, inventory feeds, appointment calendars, reporting tools, and file exchanges may each create a separate access path.

Build one table with a row for every system. Record the business purpose, dealership owner, partner role, authentication method, data available, actions allowed, logging location, review date, and offboarding step. A blank cell is not harmless. It identifies a decision nobody owns yet.

This exercise also catches shadow workflows. If the team plans to export leads into a spreadsheet because one integration is late, the spreadsheet belongs in the plan. So do its storage location, sharing permissions, retention period, and deletion owner.

The FTC dealer guidance draws a practical distinction around customer information. Records tied to financing or leasing can carry obligations that general sales or service data may not. Its separate Privacy Rule FAQs for auto dealers also explain that information can fall under the rule based on how it was collected and derived. A BDC team should not guess which fields are sensitive. The dealership should classify the data before the partner receives it.

Use named accounts and role-based permissions

Shared accounts make a fast launch look tidy while destroying accountability. When several people use one login, the audit trail cannot show who viewed a record, changed a phone number, exported a list, or closed a task.

Give each user a named account. Require the dealership's approved authentication controls. Keep administrative permissions separate from day-to-day BDC work. If temporary elevated access is necessary for setup, give it an owner and an expiration date.

Role names should describe work, not hierarchy. "Outside BDC agent" is clearer than "manager copy." A separate quality reviewer role may need recordings and notes but no export permission. A program lead may need queue configuration without access to unrelated stores. These distinctions make reviews faster because the reviewer can compare a role with a job instead of decoding a collection of inherited permissions.

The FTC guidance says covered dealers should take reasonable steps to select service providers that can maintain appropriate safeguards, require those safeguards by contract, and periodically assess the providers. Onboarding should therefore record who approved the provider, which contract covers data handling, and when the next review occurs. A signed contract does not replace the access map. The two documents answer different questions.

Define ownership before the first handoff

System access tells people what they can do. Ownership tells them what they must do.

Every active queue needs one dealership owner and one operating owner. The dealership owner decides policy, exceptions, and priorities. The operating owner watches assignment, aging, and completion. If a lead crosses departments, the handoff should create a named owner and a dated next action instead of leaving both teams attached to the same open task.

Write the exception path before launch. Who handles a customer who asks for finance details? Who reviews a record with conflicting consent notes? Who owns a service request that enters a sales campaign? How quickly must the BDC stop and escalate when the requested action falls outside its role?

This is also where lead disposition definitions matter. An outside team should not inherit vague labels and then receive coaching from reports built on those labels. Define the status, required evidence, and next action before the queue becomes a performance dashboard.

Test the access plan with real scenarios

A permission review on paper can miss the exact problem that appears during a call. Test the role with a small set of representative records.

Can the agent see enough history to avoid asking the customer to repeat information? Can the agent update the approved fields without editing protected data? Can a supervisor review the call and notes? Does an export attempt fail when the role does not require exports? Does the log show the user's action? Can the escalation owner receive and resolve an exception without giving the agent broader access?

Include one negative test for each high-risk permission. Confirm that the user cannot administer accounts, browse unrelated queues, export unrestricted lists, or open fields outside the job. A role is not verified because the happy path works. It is verified when the prohibited paths fail too.

Record the test date, the account used, the scenario, the result, and the person who approved the final role. That record gives the launch team a baseline. When permissions change later, the next reviewer can see what was intended.

Put offboarding in the launch document

Access removal often gets written after a resignation, vendor change, or emergency. That is precisely when people forget an API token, shared folder, reporting account, forwarding rule, or local file.

The onboarding plan should list every revocation step while the setup is still fresh. Disable named users. Revoke tokens and integrations. Recover dealer-owned equipment. Remove shared-folder access. Confirm how retained data will be returned, preserved, or deleted under the agreement and applicable policy. Then test that the old credentials no longer work.

Offboarding also applies to role changes. An agent who becomes a supervisor may need a different role, not the old role plus more permissions. A store added to the program should have its own approval and queue map. Access review is a recurring operating task, not a one-time launch ceremony.

The deliverable should fit on one working page

The final BDC vendor onboarding checklist does not need to be a giant security manual. It needs to point to the governing documents and make daily responsibility obvious.

Include the system map, role definitions, named owners, exception contacts, testing record, review date, and offboarding checklist. Link to the dealership's security program and vendor agreement rather than copying them into a document that will drift out of date.

A good plan lets a manager answer three questions quickly: who has access, why they have it, and how the dealership will know when that access should change. If the answer lives in three inboxes and one person's memory, the launch is not ready.

Preparing an outside BDC launch? Talk with Paramount Lead Solutions about the workflow, ownership, and access questions to settle before the first lead moves.