Automate Customer Data Updates
Reported once, logged once, written into every system that needs it: for every field, one system decides what is true. Bank details, legal name and deletion requests are never written straight through – they go to a named person as a task.
The work is not the typing, it is the deciding
Customer data never lives in one place, and there are good reasons for that. The CRM knows the contacts because that is where people make the calls; the ERP knows the invoice recipient because that is where invoices are raised; the newsletter tool keeps its own list because consent has to be evidenced. Each system got its copy when it was introduced – nobody planned this, it grew. A change, though, reaches you only once: as a call, an email, a remark at the end of an order. Whoever takes it updates the two systems they work in anyway; the rest never hear about it. The gap shows up weeks later, in returned post or in a reminder addressed to somebody who left.
Writing the value is the easy part – almost all these systems have an interface. The hard question comes first: which value applies when two systems disagree? The answer belongs not to the customer record but to the individual field. The invoice address belongs in the ERP because accounting works with it; the delivery address may be created in the shop and must still not touch it. Where two systems write into each other, the older value eventually wins at the next sync and overwrites the newer one unnoticed, because both sides report success. That is a decision, field by field, not a setting – and only someone who knows who works with which value can take it.
The second difficulty: a reported change is, at first, only a claim. An email saying “our bank details have changed” is the most common form of payment fraud and looks exactly like the genuine case; a changed signature is no evidence that the contracting party has changed. Some fields may therefore only be prepared – a person has to check and decide. A change is also not a moment but a stretch of time: while it is being verified, invoices keep going out, and what was printed yesterday stays printed. Automation also brings to light what nobody had to look at before, namely that the same customer exists three times. The effort in this project sits in the field list, not in the workflow around it.
Which changes actually come in
We start with the type of change that occurs most often and has the fewest special cases. Further types later share the same field list, the same approvals and the same log.
Addresses and invoice details
The most common starting point: a move, a second site, a separate invoice address – and the delivery address deliberately does not follow.
Contacts and responsibilities
Ms Brand leaves, Mr Yilmaz takes over. Role, mailbox and extension move with the job; marketing consent belongs to the person and stays behind.
Channels and consent
Invoices by email instead of post, newsletter cancelled, portal access for two more people – small changes that live in three systems.
Payment details and terms
IBAN, direct debit mandate, payment terms. The automation only prepares: it captures the details, checks the format and hands accounting a task.
Legal name, legal form, takeover
A limited company becomes a partnership, a business is taken over. That changes the contracting party and needs evidence, not a new signature.
Suspension, departure, deletion
A contact should get no more marketing, an account should be closed. What may be deleted and what must be retained is not the automation's call.
One record, one working day, five changes
The change log of a single customer: per row the field, the previous and the new value, the source and the time. Three rows are written, one is waiting for approval, one is not written at all.
Change log · record K-10482 “Meier Haustechnik GmbH” · one working day
| Field | Value | Source and time | State |
|---|---|---|---|
| Invoice addressowned by: ERP |
before |
Customer portal, signed in | writtenERP · CRM · shipping |
| Purchasing contactowned by: CRM |
before |
Email from the registered domain | writtenCRM · ticketing |
| Newsletter deliberately unchanged: consent belongs to the person, not to the role. Ms Yilmaz is in the CRM but not on the mailing list. | |||
| Main phone numberowned by: CRM |
before |
Phone note, confirmed on the call | writtenCRM · phone system |
| Bank detailsowned by: ERP |
before |
Email with a PDF attached | approval neededwritten to no destination yet |
| Legal nameowned by: ERP |
before |
Email, changed signature | not writtenConflict: since yesterday the ERP holds “Meier Gebäudetechnik GmbH & Co. KG” |
Open approval · bank details
- Task for
- Accounting, open since 11:47
- Before approval
- Call back on the number held in the master record – never the number from the email
- Until then
- The previous bank details stay active, including for Friday's payment run
Approval and rejection are written into the same row, with name, time and reason.
The column that matters is not “new” but “source and time”. It answers the question asked months later: who reported this, and why was it accepted?
Payment details and anything touching the contracting party always carry an approval; that part is not up for negotiation. Which further fields get one, and how the checking instruction inside it reads, you settle in the intro call – the box above is our proposal, not an assumption about your business.
From the report to the last destination system
-
Receive the report and match it
Reports arrive by form, shared mailbox or phone note. Each is matched to one record by customer number, sender address or contract number; what cannot be matched goes to the exceptions list.
-
Split into fields, pull the rule
One report becomes individual field changes. For each field the rule table states the owning system, the destinations and whether an approval sits in front.
-
Check what can be checked
Mandatory entries, formats and plausibility: IBAN check digits, postcode against town, sender domain against the one on file. No identity check – it catches typos and clumsy forgeries.
-
Approve where you have asked for it
Fields you flagged for approval are not written but assigned to a role as a task – old value, new value, source and the checking instruction you wrote for it. A rejection needs a reason; both land in the same log entry.
-
Write, log, report back
The owning system first, then the destinations; the log records for each whether the value arrived. If one fails, the case stays visibly open instead of half done. The customer is told what was applied.
What changes day to day
Today
- The change sits in an email in a mailbox
- Whoever reads it updates the two systems they know
- A missing destination shows up in returned post
- For bank details, whoever has time makes the call
- Who changed what, and when, nobody knows
With a field list and a log
- The change is a case with a state and an owner
- Written to every destination the field defines
- If a destination fails, the case stays visibly open
- Bank details go out as a task with instructions
- Field, old value, new value, source, timestamp
Where automation stops with master data
Master data is where poor data quality comes back to bite. We put these four points on the table before we write an offer:
- Whether a report is genuine is settled by a person on the telephone, not by software. An email from the right domain proves nothing, and where bank details are concerned the forged change is the norm rather than the exception. The approval we build around it is therefore real work and not a formality: somebody has to pick up the phone every single time, including for the customer you have invoiced for three years. If you expect the automation to take that judgement off your hands, or even to speed it up, this is the wrong product.
- Where the same customer has been created more than once, automation makes matters worse. The change lands on one of the three records; the other two are then not merely stale but provably wrong, and nobody can see which one counts. Cleaning CRM data and merging duplicate records under controlled approval is a project in its own right and belongs before this one, not alongside it. If that describes your data, we will tell you not to buy yet and to spend the budget on the clean-up instead.
- Which system owns which field is a decision, not a setting. Sales and accounting disagree about where the correct address lives, and both sides have reasons. Reaching that agreement is the slowest part of the project, it can take longer than the build, and it costs meetings in your office rather than hours in ours. You have to reach it yourselves – we can write it down and implement it, we cannot broker it.
- None of this improves the data you already hold. The workflow only touches records that somebody reports a change for, so every wrong address that nobody mentions stays exactly as wrong as it was. And if only a handful of changes reach you in a month, agreeing the field list will cost you more time than the workflow saves in its first year. In that case a short checklist beside the mailbox is the more honest tool, and we will say so in the intro call.
Works with the systems you already run
Scope and price
The entry price covers one intake route, one field list and three destination systems with logging and approvals. What moves the price, we say before the quote.
- One intake route: form, shared mailbox or both
- Rule table for up to twelve fields with an owner
- Three destination systems connected read and write
- Approval task with instructions for critical fields
- Change log on the record, exportable
- Exceptions list for anything that cannot be matched
- Documentation, handover session and 30 days of support
What increases the price
- More than three destinations, or one without an interface
- Self-service in a customer portal instead of email reports
- Two approval stages or four-eyes review for payment details
- Matching and merging duplicate records beforehand
- Address verification against a directory, not just formats
Self-service in a customer portal, more than three destination systems and a duplicate clean-up typically land in the range of our Workflow Advanced package from €2,490. We quote the binding fixed price after the intro call.
All prices excl. VAT · operation and further development optionally via a support package
What you get
-
Production change flow
Set up from intake to the last destination system, signed off with real reports
-
Field list with owning systems
Per field: who owns it, where it is written, who approves it – one page, yours to change
-
Change log and exceptions list
Every change with source, time and destination; the unresolved collects in one place
-
Training for your team
How an approval is decided and what to do when a destination system fails
Frequently asked questions about customer data updates
These solutions fit alongside
Lead Capture with CRM Integration
The start of the record: what is captured properly here needs correcting less often.
Automated Customer Onboarding
The first complete master record – including fields nobody fills in later.
Approval Workflows
The same approval logic for other decisions: task, deadline, history, log.
Spreadsheet Data Sync
For the lists beside the systems that still need keeping.
How many systems hold your customer's address?
In the free intro call we take one real change report from last week and walk through it: which fields it touches, which system owns each one, who decides on bank details. Afterwards you know whether your field list holds – or whether duplicates come first.
Book a free intro callWhere automated customer data updates creates value in everyday work
The workflow captures change requests in a structured format, validates identity and required data, requests approval where needed and synchronises affected systems.
Three concrete operating scenarios to compare with your own process.Change billing address
Validated details update CRM, ERP and open master records together.
Change contact person
New contact, role and communication status are applied consistently.
Update company name
Broad changes move with evidence and approval to the right systems.
A strong fit when …
Recurring office tasks follow clear rules, consume small blocks of time every day and should run reliably without replacing existing systems.
- You handle recurring change requests using repeatable rules.
- The intake, target system and accountable business role can be named clearly.
- Exceptions are allowed to remain visible and move to people deliberately.
Deliberate automation boundary
Bank details, contracting parties, deletion requests and unverifiable identity changes are processed only after additional human review.
Explore the technical approach and platformsEstimate time savings with your own volume
The calculator uses 14 minutes today and 4 minutes after automation as fixed example assumptions. It does not replace process analysis.
Illustrative estimate based on the visible assumptions — not a guarantee.