Home · Solutions · Legal & compliance
Solution · Legal & complianceThe same person exists three times; the consent that decides whether you may write exists once
One customer across three brands, one consent record
Robots match customers across the group's DMS instances and CRM on identifiers that carry weight, and hold every consent once, per purpose, channel and company.
Executive summary
A reminder goes to someone who opted out, because the objection lives in another brand's system.
We build two things the group's systems cannot build for themselves: a person record above the four customer files.
A person is contacted once instead of three times, and the contact carries the history the group already holds.
the person record and consent register; each brand system and the CRM, for the link and the consent state; the mailing tool's suppression list
Business problem
Customer data
A dealer group does not choose to keep its customers in several places. Each manufacturer contract brings its own dealer management system, and a group CRM is bought on top because none of them speaks to the others. Someone who owns a family car from one brand, drives a company car from another and services both at the group's workshops is three records by construction, with three addresses and, if anyone captured them, three sets of consents. In 2025, 411,000 of the 597,400 new passenger cars registered in Poland went to companies rather than private buyers (PZPM and KPMG, February 2026), which is one reason so many customers exist twice: once as a person, once as a company contact.
What breaks is not the data, it is every decision that rests on it. Marketing decides who may receive an invitation, aftersales who may be reminded an inspection is due, and a site director has to answer the customer who says he already told somebody no. Each answers from a different system, and none can see whether the consent behind the name covered this brand, this channel and this company. The work lands on people never hired to reconcile databases.
How it works today
What we find in multi-brand groups before anything is joined up:
- PersonA service adviser cannot find the customer in this brand's system and creates a new record from the booking note
- SystemThe group CRM takes an export from each system and keeps whichever version arrived last
- PersonMarketing builds a campaign list from three exports and removes by eye what looks like the same person twice
- WaitingA withdrawal sent to the group's address waits until a coordinator applies it, in the one system they think of
- Risk of errorA reminder reaches a person who objected at another site, where the objection is still the only copy
- PersonA data-subject request is answered by asking four system owners to search on a surname
Why the current process costs more than it appears
Time that disappears before anyone measures it.
- Duplicates are created faster than they are removed: every hurried record at a service counter, every sign-in sheet typed up after an event and every lead pushed in from a portal adds another version of a person already there.
- Consent is treated as a property of a record rather than of a person, so it multiplies with the duplicates. The same customer is opted in on one record, opted out on the second and silent on the third, and which one wins depends on the export the list came from.
- Reach is lost quietly. A group that cannot prove a consent stops using the channel for a whole segment, and a message sent without a basis leaves a complaint at a site rather than a record anyone counts.
Cost of inaction
A consent that cannot be evidenced still sends. That is what keeps this arrangement in place: campaigns go out, reminders arrive, and the only visible symptom is the customer asking a site director why the group wrote again after he said no. Nobody escalates a duplicate.
The exposure grows with the group. Each brand contract adds a fifth system, each dealership bought arrives with its own customer file and consent wording, and the objection made two years ago at a site since sold sits where nobody will look. The hours above price cleanly. What does not is the afternoon spent reconstructing, from four systems and a spreadsheet, why a named person was written to last spring.
A plausible organisation with realistic proportions. The figures are there to be recalculated on your data; they are not a client result.
A Polish dealer group in two operating companies: one holds two volume-brand contracts across five sites, the other the premium brand at two. Three dealer management systems, a group CRM, a mailing tool and Microsoft 365 E3.
68,000 customer records across the four systems. About 3,100 record changes a month (new customers, corrected addresses and numbers, vehicle changes, records touched at service reception) and 240 consent events, given, withdrawn or objected.
Each system is maintained where the work happens, and the CRM takes exports that overwrite rather than reconcile. Consents sit on four forms whose wording has changed twice, and withdrawals are applied by hand.
No system holds the person, so nothing holds the consent either. Outbound lists are rebuilt from exports and cleaned by judgement, and an objection lands wherever whoever applies it happens to look.
Robots read changes from each system, resolve the same person on identifiers that carry weight and send anything uncertain to a data steward in Microsoft Teams. One register holds each consent per purpose, channel and controlling company, with its source, wording and date, and every outbound run asks it first.
Reconciliation falls to confirmations and real exceptions, a withdrawal reaches every system the day it is made, and each send carries the consent it relied on. Illustrative figures, not a client result.
Proposed solution
We build two things the group's systems cannot build for themselves: a person record above the four customer files, and a consent register every outbound process has to ask. Robots read new and changed customers from each dealer management system and the CRM, normalise what can be normalised, and resolve the same human being only on identifiers that carry weight, never on a name and a town. What the strong keys leave open goes to a data steward in Microsoft Teams, with both records side by side.
Nothing is overwritten: each source record keeps its own key and gains a link. The register holds one row per person, purpose, channel and controlling company, with where it was captured, which wording was shown and when. Every outbound run asks it first, so the filter belongs to the flow rather than to whoever built the list, and the answer is stored with the campaign. A withdrawal on any channel reaches the register, the mailing tool's suppression list and each source system the same day. A recall or safety campaign is not marketing, is marked as such, and is never gated by a consent.
UiPath Orchestrator queues, triggers, credential stores and audit; UiPath Data Fabric entities, relationships, row-level access and audit history; UiPath Action Center tasks inside Microsoft Teams; UiPath Integration Service connectors for Microsoft Teams, Microsoft Outlook 365 and Microsoft OneDrive & SharePoint, plus Connector Builder; Microsoft Purview retention; Microsoft Power BI
The person and consent model, the matching rules and thresholds, the merge task, the consent capture points and register write-back, the consent check every outbound process calls, the withdrawal job and the reporting
Each dealer management system through the interface its vendor provides for your installation, and through the application screen where none exists; the group CRM API; the mailing tool's suppression endpoints
How the automated process works
- AutomationRobots read new and changed customers from each brand system and the CRM on a schedule and normalise names, addresses and identifiers
- AutomationCandidates are built only from strong keys: a vehicle the group sold or serviced, a business tax identifier, a contract or repair-order number, a confirmed e‑mail or mobile number
- PersonAnything below the certain-match threshold reaches a data steward as an Action Center task in Microsoft Teams; nothing merges on a name alone
- AutomationThe confirmed person gets one group identifier and a link written back into each source record, otherwise untouched
- AutomationConsent events from every capture point, from the showroom tablet to the unsubscribe link, reach the register with purpose, channel, company, wording, source and date
- AutomationEvery outbound run asks the register first: the list is filtered per person, purpose, channel and company, and the answer is logged with the campaign
- AutomationA withdrawal is applied the same day to the register, the suppression list and each source system, and a Power BI page shows coverage and what is unresolved
Human-in-the-loop model
Automation handles
- Reading changed records from every system, normalising them and proposing candidates from strong keys only
- Writing each consent event to the register with its purpose, channel, company, wording, source and date
- Filtering every outbound list against the register and applying withdrawals to all four systems the same day
People decide
- Whether two records are the same person, whenever the strong keys do not settle it
- Which purposes, channels and companies a consent wording actually covers, and how a new wording is versioned
- Whether a message is marketing at all: a recall or safety campaign contact is not, and is not gated by a consent
Before and after
Systems and integrations
Where a rule suffices we do not use a model. Where judgement is needed, a person decides.
Inputs
- three brand dealer management systems
- the group CRM
- web and showroom consent forms
- unsubscribe links and the group's privacy mailbox
- event sign-in lists
Automation layer
- UiPath Orchestrator
- UiPath Robots
- UiPath Integration Service
- UiPath Data Fabric
- UiPath Action Center
Target systems
- the person record and consent register
- each brand system and the CRM, for the link and the consent state
- the mailing tool's suppression list
Human touchpoints: Action Center merge tasks in Microsoft Teams; a Teams channel for the daily exception digest; the Power BI page
Technologies used
read and write each brand system and the CRM on a schedule, queue candidates and consent events, retry and audit
Aholds the person record, its links to each source key and the consent rows, with relationships, row-level access and audit history
Amerge confirmations and consent exceptions decided by a data steward without leaving Teams
Areaches the CRM, the mailing tool and the group's mailboxes
Aretention and disposition for the register and the evidence exports, and the audit log behind them
Aconsent coverage by purpose and channel, duplicate rate per system, unresolved candidates
AIllustrative economic model
Start by questioning the assumptions.
Duplicates are the reason this arithmetic exists, so the unit is a touched record rather than a customer: 3,100 record changes and 240 consent events a month, 3,340 in all, at five minutes each across the systems holding the same person twice. €23 an hour is a fully loaded back-office cost in Poland. Nothing was measured at a client.
Run the numbers on your data
An illustrative estimate from your own inputs. It models released capacity; it is not a promise of savings.
Business benefits
- A person is contacted once instead of three times, and the contact carries the history the group already holds
- Every send can be evidenced afterwards: who was on the list, on which consent, captured where, in what wording and when
- A withdrawal reaches every brand, site and system the day it is made, rather than at the next export or never
- Service reminders, tyre-season offers and event invitations are planned against a real consented audience, so the group knows what it may send before it commits the budget
The management view
- The group can state, per operating company and per brand, how many customers it may lawfully approach, by purpose and channel
- A data-subject request is answered from one person record and its links instead of four searches on a surname
- Customer counts stop being an argument: the board and the marketing plan both count people, and the gap between record and person is measured
Board-level KPIs
Security and governance
Control is not an add-on.
- Robots read each brand system and the CRM through dedicated accounts limited to the customer tables the design names; write-back covers the link and the consent state and nothing else, and no password appears in a workflow
- Consent rows are versioned, never overwritten: a withdrawal is a new row with its own timestamp and the wording actually shown beside it, so what was agreed to can be reproduced years later
- The two operating companies stay apart, each consent naming the company and brands it covers, and the register records what was consented rather than a second copy of the customer file, under retention rules in Microsoft Purview and with the automation layer in the European Union region of UiPath Automation Cloud
Why now
Two legal layers apply and they are not the same one. Regulation (EU) 2016/679 decides whether the group may process a person's data for marketing at all; art. 398 of the Polish Prawo komunikacji elektronicznej decides whether e‑mail, SMS or the telephone may carry it. A consent record without the channel cannot answer the second question
Under Article 21(2) of Regulation (EU) 2016/679 a person may object to direct marketing at any time and the processing must stop. A group applying that objection in one brand's system and not the others has not stopped it, and each new contract multiplies the places it must reach
No new platform is needed: robots read the systems the group already runs, the register is a data model rather than a migration, and the modelled €6,402 a month of back-office time is what waiting costs
Relevant executive roles
One answer to how many customers the group has and how many of them it may lawfully approach, per brand and per company
Inspection and tyre-season reminders are the most repeatable revenue contact the workshops have, and they work only when the channel a customer accepted is known
Consent, objection and withdrawal become records with a source, a wording version and a date, instead of a state reconstructed from four systems
Common questions and objections
Nothing is merged inside them. Each brand record keeps its own key and stays where it is; the group gains a person record above them saying these three are the same human being, plus a link written back. Where a system cannot accept even a link field, the person record still resolves outbound lists and data-subject requests.
Only where the wording names the controlling company and the brands it covers, and the purposes and channels are specific. Where brands sit in two companies, a consent given to one does not extend to the other. The register keeps them apart, and the honest answer is often to re-ask once, on wording that covers what the group intends to send.
No, and it must not. A recall or safety campaign contact is not marketing: it rests on its own basis and stays limited to the recall. Because the register records the purpose, the flow tells the difference instead of leaving it to the list builder.
When this is not the right solution
- One brand, one system and one legal entity: the duplicates sit inside a single database, and its own de-duplication plus one tidy consent form will cost far less than this
- Nobody will own the decisions. This needs a data steward who confirms merges and somebody in legal who says what each wording covers; without both, the register becomes a fifth place where consent disagrees with itself
A question for the next management meeting
How many actual people are behind the customer records this group keeps in its brand systems and its CRM, and for how many of them could we produce today the consent that would let us send next month's campaign?
Implementation approach
We start with one slice of the process and extend only once it is proven.
We deliver
- A survey of the four systems: which fields each holds, which identifiers are reliable, what the strong keys resolve
- The person and consent model, linked back to every source key so no brand system is overwritten
- The matching rules, the certain-match threshold and the merge task in Microsoft Teams
- The consent capture points, the register write-back, the same-day withdrawal job, the consent check every outbound process calls, the Power BI page and a runbook the data steward owns
We need from you
- An export of the customer tables from each brand system and the CRM, with the fields you will match on
- The consent wordings in use today and, for each, which company and brands it names
- A named data steward, and a decision on who confirms a merge and who approves a wording
Stages
Discovery
The four systems, their identifiers, the wordings in use, what the strong keys resolve
Design
The person and consent model, matching rules and thresholds, the brand and company map, security
Build
Robots, the register, the merge task in Teams, the consent check and the withdrawal job
Validation
A replay on historical records and past campaigns against what marketing and legal would decide
Go-live
Read-only first, then write-back per system under supervision, then the consent check before the first campaign
Departmental. Effort is driven by the number of brand systems and how each can be read, the quality of your identifiers, and how many consent wordings the group has collected.
The same person, three records, and only one of them knows he said no.
Export the customer table from each system and send us the consent wordings you use today. We come back with your duplicate rate, the share your strong identifiers resolve, and a written view of which wording covers which brand.
Run the match on one export per systemThe neighbouring process usually has the same problem
The pipeline review starts with an argument about the data, not about the deals.
View solution Legal & complianceData-subject requests answered in days, not at the deadlineStop answering GDPR requests by hand on day twenty-eight of a thirty-day clock.
View solution Sales & marketingCustomer events that end in leads, not name badgesGuest lists from three DMS exports, RSVPs in four inboxes, a sign-in sheet in a drawer, the importer waiting for proof.
View solutionIndustries we deliver this in most oftenAutomotive retail