CRM for auto brokers: what belongs inside one
A broker does not sell a car off a lot. He finds the car across a network of dealers and gets the buyer financed, and whether he earns anything is decided by a credit application.
By Eugene Romanov·Published
The short answer
An auto broker's system needs three things a general sales CRM has no fields for: a credit application complete enough that a lender will not return it, a Social Security number stored as ciphertext with every disclosure written to an access log, and one profit rule that the dashboard, the leaderboard and the reports all read rather than each computing their own. A system like this runs in production for a broker in Staten Island. A build starts at $2,000 and takes 30 to 45 days.
SHT-02What drives the number
The credit application is a legal document, not a contact form
It is long, dull and consequential, and a lender will send the whole thing back over one missing section. The most common failure in off-the-shelf tooling is the co-applicant: they get a trimmed version of the form, and the file bounces. In the production system the co-applicant renders the same component as the primary applicant, so both answer the same thirty-five questions and both upload both sides of a licence. Four more fields become required automatically when time at the current address is under two years, because the lender will ask anyway. The completeness check runs the same list server-side for each person, so a trimmed co-applicant is not something that can happen by accident.
The Social Security number is ciphertext, and every look at it is written down
AES-256-GCM, with the key held only in the server environment: never sent to the browser, never stored in the database. There is no plaintext fallback, so a missing key refuses the submission rather than saving it in the clear. Revealing a full number writes to an access log first, and the disclosure depends on that write succeeding, which means a number cannot be read without a record that it was read. Two keys are supported at once so a rotation has no window in which an application submitted mid-change becomes unreadable. That is not hypothetical: a real application arrived during the afternoon the rotation was written.
One profit rule, or four screens that disagree
Before the rewrite, profit on a deal was computed in four places and answered three different ways on the same day: the dashboard tile, the leaderboard two rows below it, the reports page, and the broker's own row. Four places computing one number three ways is worse than any single one of them being wrong, because then no screen can be trusted. The rule now exists once in the application and once in SQL, and the two move in one commit or neither moves. With no revenue recorded, profit reports as unknown rather than as a loss, and costs already spent are shown separately rather than dropped, because hiding them would overstate profit, which is the opposite lie.
Payouts read the same rule the reports do
A broker sees his own deals and his own payout. The company sees all of them and can say what each deal made, to the broker, to the accountant and to itself. Payouts are computed from the same money model as the reports rather than from a spreadsheet kept alongside, because two sources for one number produce two truths and one unpleasant conversation at the end of the month.
The site and the system are one program
The public website and the CRM are route groups in one application on one deployment, so there is nothing to integrate between them. A form filled in on the site is a row in the pipeline a second later, with nothing retyped and nothing waiting in an inbox. For a broker that means a lead from advertising is in the pipeline before anyone has had time to forget about it.
Lease dates are the one reason to call that is known in advance
A lease ends on a calendar. Scheduled jobs surface those dates and raise the reminder, alongside the parts of handling personal data nobody should have to remember: retention of the sensitive fields, and re-keying when the encryption key changes. Anything that cannot be trusted to human memory belongs on a schedule.
SHT-03The options, side by side
What each route actually costs you.
| Option | Price | Timeline | The trade-off |
|---|---|---|---|
| General sales CRM | Per seat, per month | Same day | Models a deal moving toward a signature. Has no place for a credit application, no safe home for a Social Security number, and no opinion about how profit is computed. |
| Dealer software | Per seat or per rooftop | Weeks | Built around inventory on a lot. A broker has no lot: the car is found across a network, and the product's central assumption is the one that does not apply. |
| Spreadsheets plus a form service | Low, in software | Already there | Works until a lender returns a file or someone emails a Social Security number. The failure is not volume, it is that nothing guards completeness or disclosure. |
| A system built for the trade | From $2,000 | 30-45 days | The application, the encryption and the money model are the product rather than fields bolted onto one. More expensive up front, and it needs one person inside the company to own how it behaves. |
SHT-04General notes
The questions people actually ask.
- N01Why can a broker not just use a normal CRM?
- Because a normal CRM ends the deal at the signature and has no fields for the credit application, no safe storage for a Social Security number, and no single definition of profit. For a broker those three things are the work.
- N02Is it safe to hold Social Security numbers in my own system?
- It is exactly as safe as the storage design. Here that means AES-256-GCM, the key held only on the server, a missing key refusing the submission rather than saving in the clear, and every reveal of a full number written to an access log before the number is shown.
- N03What happens when the encryption key is rotated?
- Two keys are supported at once, so an application submitted during the rotation stays readable. A scheduled job re-keys the stored values afterwards.
- N04Can each broker see only their own deals?
- Yes. Permissions are built around the deal and the branch, and payouts are computed from the same rule as the company reports, so the month does not end with two versions of one number.
- N05Can the public site and the CRM be one build?
- They already are in the production system: route groups in one application on one deployment. A form on the site becomes a pipeline row a second later, with nothing retyped.
- N06What does it cost?
- From $2,000 over 30 to 45 days for the system, from $1,200 over 10 to 14 days for the site. A $500 Blueprint is credited 100% toward a build within 60 days, and the audit is free. No discounts, ever.