Why customer programmes fail on the data question, even when the concept is sound

The concept was good. The programme has stalled anyway.

The management of a mid-sized company decides on a customer programme, such as a bonus scheme for regular customers or a continuous customer journey from first purchase to repeat order. The concept is convincing. The budget is approved, and the kickoff takes place.

A few weeks later, the project has stalled. It is stuck on questions nobody can answer:

• Where does the purchase data come from: the ERP system, the online shop or both?
• Who may change the address fields: sales, customer service or marketing?
• Which consent applies when two systems say different things?

Each of these questions ends up in an alignment meeting. IT points to marketing, marketing to sales. As long as nobody decides, the programme waits.

Customer programmes rarely fail because of the concept. They get stuck because it has not been settled who is responsible for which customer data.

Where customer programmes really get stuck

Usually three weak points come together.

First weak point: the customer data sits in four places. The billing address is in the ERP, the system for inventory management and accounting. Contact persons and the latest sales note are in the CRM. Online orders sit in the shop; newsletter consent and open rates in the email tool. Each system does its job. None of them knows the whole customer. Yet that is exactly what a loyalty programme needs: who bought what, who may be contacted, what the points balance is. Anyone who tries to bring the data together often finds the same customer in three systems under three spellings.

Second weak point: nobody feels responsible for data quality. Duplicate records, outdated addresses, empty mandatory fields. Everyone in the company knows the problem, and nobody fixes it. Sales maintains what it needs to close the deal. Customer service corrects what it notices during a call. Nobody keeps an eye on the customer base as a whole.

Third weak point: there is a no man's land between IT and marketing. IT provides interfaces. Marketing is responsible for content, campaigns and the programme. Both do their part correctly. What remains open is what happens between the systems. Which system is right when two addresses contradict each other? Who notices that the nightly transfer from the shop to the email tool has been failing for days? Who approves a new field flowing into the programme? Often, quite simply, nobody is responsible for this data flow.

The pattern is not limited to mid-sized companies. In a survey of 310 loyalty and marketing decision-makers published in May 2026, carried out by Forrester on behalf of the software vendor Zeta Global, 91% say that data-related hurdles are slowing them down. 68% state that their loyalty data is only partly connected to other systems. The study names data quality, fragmented systems and organisational silos as the brakes. Only 26% consider their programme very effective.

The study was commissioned by a vendor that benefits from this finding. It does not list ownership as a category of its own. But if you look closely at scattered systems and departmental silos, you usually end up at the same open question: who is responsible for this data, and who decides when something goes wrong?

A look at the customer journey shows why this carries so much weight. From the company's point of view, it is a chain of handovers: order in the shop, invoice from the ERP, welcome email from the email tool, call from sales. At every handover, information moves from one system to the next. If the flow breaks, the customer notices. In the email with the wrong name. In the voucher for a product they have just sent back.

A customer programme builds on exactly these flows. It cannot be better than the data that reaches it. So who is responsible for which section of the flow has to be settled at the start of the project. The self-test for journey maps checks where your map only assumes the transitions rather than observes them.

Why nobody asks this question before the kickoff

The question is rarely left open out of carelessness. It falls through the cracks because of the way customer programmes come about.

The impetus comes from marketing or sales. The goal is a business one: retain regular customers, increase repeat purchases, win back inactive customers. Whoever initiates a programme like this thinks in target groups, offers and communication flows. Where the purchase history comes from and which system is right in case of doubt lies outside that field of view. Until now, it was not their job either.

Data questions are seen as a technical detail. In the concept phase, you often hear: "IT will sort that out." IT can build interfaces. It cannot decide which address applies when the CRM and the shop hold different versions. That is a business decision, and it needs an owner in the business unit. The article on CRM systems that lose value gradually shows that missing ownership also erodes systems that are already running.

Then there is data protection. The GDPR sets out an accountability obligation in Article 5(2). What follows from it for your company is for your data protection officer to assess. Either way, it helps the project if it is settled who is responsible for which customer data. With consents, that is the first thing we ask about in projects.

Budget approval is based on the concept rather than on feasibility. Committees decide on what is put in front of them: benefit, mechanics, costs for software and implementation. Whether the necessary data exists in usable quality, and who maintains it, rarely appears in the decision paper. The survey mentioned above shows the tension: 92% plan to invest in technology or processes in the next twelve months, while 91% report data-related hurdles. The money is there. A settled data foundation often is not.

The consequence: the clarification gets pushed into the running project. The open questions surface later, usually when the first data pipeline is due to be built. Then marketing, sales, IT and customer service sit in alignment meetings while the schedule, service providers and budget are already running. Every unresolved responsibility blocks the work packages that depend on it. Before the kickoff, the same clarification would have cost one well-prepared meeting. In the middle of implementation it costs considerably more, because paid work stands still.

What a data ownership mapping is and what it is not

A data ownership mapping is a single page. It lists all the types of data your customer programme needs. For each data type, the page answers five questions:

1. Created in: in which system is the information first recorded?
2. Maintained by: which role corrects errors and keeps the records up to date?
3. Approved by: which role decides whether and how the programme may use the data?
4. Called when errors occur: whom does customer service call when something is wrong?
5. Route into the programme: automatically via an interface, manually by export, or still open?

Each cell needs a concrete role, meaning a function held by exactly one person. "Team lead, internal sales" is a role. "Sales" or "IT" is a collective address and is not enough. Use roles instead of names, because people change and responsibilities should stay.

This is what the page can look like. The entries are an invented example:

The question marks are deliberate. The page is meant to show exactly these gaps before the programme starts.

What the mapping is not

Not a large data governance project. Data governance means a company-wide set of rules for handling data. Gartner predicted in February 2024 that by 2027, 80% of data and analytics governance initiatives will fail. The reasoning: a programme that does not enable prioritised business outcomes fails. The mapping pursues exactly one outcome: that a specific programme can start. All other data in the company stays out of scope.

Not a tool purchase. A spreadsheet, a whiteboard or a shared document is enough. Software does not answer any question of responsibility. According to a Gartner survey from 2023, marketing departments by their own estimate use only 33% of the capabilities of their marketing technology, down from 42% the year before. That argues against trying to close a responsibility gap with yet another tool.

Not a data strategy. The mapping does not settle where your company wants to be with its data in five years. It describes who is responsible today for the data that this one programme needs. That is why a workshop is enough and you don't need a project.

Not a legal review. The mapping documents responsibilities. It does not assess whether your consents and processes meet the requirements of the GDPR. That remains the job of your data protection officer or your legal counsel.

How to build the mapping in a workshop

You don't need a BI team for this. You need the right people at one table, the prepared spreadsheet and a facilitator who insists on a concrete answer for every data type.

Who belongs at the table

Invite the people who handle the data day to day. The heads of department alone are not enough.

• Sales: knows customer master data, terms and the question of who a customer "belongs" to.
• Marketing: is responsible for campaigns, the email tool and usually the concept of the programme.
• IT: knows which systems exist, and where interfaces run and where they don't.
• Customer service: is the first to see when data is wrong, because that is where customers get in touch.
• Data protection, if you have it: belongs at the table as soon as consents or contact details are involved.

The decisive factor is one person who is allowed to decide. Without them, the workshop ends with open questions that nobody can close.

Guiding questions for each data type

Prepare the spreadsheet with the six columns shown above. Then go through the data types one by one:

Master data: in which system is the address "correct" when two systems hold different details? Who may change address fields, and does the change reach all the other systems?

Purchase history: where does the purchase data come from: the ERP, the shop or both? How current does it need to be for the programme, and how current is it today?

Consents: where is it recorded who has agreed to which kind of contact? Who makes sure that a withdrawal of consent arrives everywhere, including in the email tool?

Interactions: which contacts with service, sales and campaigns are recorded at all, and where? Who decides which of them the programme uses?

Points balances: where is the balance calculated, and who is responsible when a customer disputes it? What happens to the balance when customer accounts are merged?

Silence in response to a question is a result, and it is exactly the one you are looking for. Enter it as an open point, with a role that will clarify it by a fixed date.

How to run the meeting

Keep the scope narrow: the data types of this one programme, and not the company's entire data landscape. Discussions about new tools or a data strategy go on a list of parked topics. Fill in the spreadsheet directly in the room, visible to everyone. Then the participants object straight away if an entry is wrong, instead of weeks later.

At the end you have a completed page, plus a list of open points with owners. It belongs in the documents for the budget decision.

The three warning signs in the finished mapping

A mapping without gaps is rare, and gaps are no reason to stop the project. Three patterns deserve a close look, though. Each comes with the same question: does this have to be solved before the start, or can the programme get going with an interim solution?

1. Data types without a named role

What it looks like: under "Maintained by" or "Called when errors occur" there is a question mark or a collective address such as "IT". This often affects interaction data such as opens, clicks or service enquiries. They arise in several tools, and nobody feels responsible.

Why it matters: without a named role, every data error stays unresolved until a customer notices it. Then the search for whoever is responsible begins while the programme is already running.

Solve before the start if consents or other data relevant to data protection are affected. In projects, we treat a question mark in this row as a launch risk. Agree with your data protection officer what the evidence should look like.

Interim solution possible for data the programme initially uses only for analysis. Fill the role on an acting basis and set a date by which ownership will be settled for good.

2. Data types with competing sources

What it looks like: under "Created in" there are two or three systems. The delivery address exists in the ERP, the shop and the CRM. The purchase history sits in the inventory management system and in the shop, and the two count returns differently.

Why it matters: as long as it has not been decided which system applies, the programme calculates with values that contradict each other.

Solve before the start for all data from which the programme calculates something for the customer, meaning purchase history and points balances. Define one leading system for each data type: the system whose value applies in case of doubt and to which all others are aligned. This decision takes one meeting. No software is needed.

Interim solution possible for master data such as addresses, if a leading system has been designated and the other sources only read for the time being. The technical alignment can follow.

3. Data flows that only run manually via spreadsheets

What it looks like: under "Route into the programme" it says "Export". Every week, someone pulls a list from the ERP and uploads it into the email tool. That works as long as this person is there and remembers to do it.

Why it matters: manual flows are not wrong, but they are fragile. A holiday, an illness or a changed column in the export is enough for the flow to break off unnoticed. And anything transferred only weekly is up to a week old in the programme.

Solve before the start if the customer sees the data directly and expects it promptly. A points balance that only appears days after the purchase generates queries in customer service and costs trust in the programme.

Interim solution possible for internal analysis and manageable volumes. Prerequisites: a fixed rhythm, a named role with a deputy, and short written instructions. Then the spreadsheet is a deliberate interim step.

The rule of thumb

Two test questions usually settle "now or later" reliably. Does the gap affect legal obligations, for example around consents? Does the customer see the result directly? If either answer is yes, the gap belongs before the start. Everything else can get going with an interim solution, provided it has a responsible role and an end date. If either is missing, the stopgap becomes permanent.

Why the mapping should become standard

One sheet of paper sounds like very little, and that is intentional. The mapping costs one workshop and some follow-up work. In return, it changes three things on which the course of a customer programme depends.

Risks become visible before money is spent. Without a mapping, you decide on budget and schedule on the basis of the concept. With a mapping, you see in advance whether the purchase history exists in the required form and who supplies it. A data type without an owner is then a project risk that is on the table before you sign. How to measure the programme's benefit later is covered in proving the return on journey measures.

Alignment loops get shorter. The questions from the beginning do not go away. They are asked earlier, once, with everyone involved at the table. If someone asks during implementation who supplies the purchase history, a glance at the page is enough. How much time this saves depends on the project. Often it removes a large share of the clarification meetings that would otherwise pile up in the middle of the project.

The business side and IT talk about the same thing. Marketing thinks in target groups and campaigns, IT in systems and interfaces. The mapping brings both views down to a shared unit: the data type. Both sides can negotiate on that basis without learning the other's jargon. As a side effect, whoever is responsible for data protection in your company has a documented starting point. That does not replace a data protection review.

This is how we at UNIT ONE approach customer systems: first settle the structure, then build the programme. That is why the mapping belongs before every budget approval as a fixed prerequisite.

Your next step

If a journey or loyalty programme is coming up in your company, reverse the usual order:

1. Schedule a meeting before the budget is approved. With sales, marketing, IT and customer service, and where consents are involved, also with the person responsible for data protection in your company.
2. Create one row for each data type in the programme and fill in the six columns.
3. Mark the warning signs: missing roles, competing sources, manual flows. For each one, decide: solve before the start, or an interim solution with a role and an end date?
4. Only then talk about budget and schedule, based on what can actually be implemented.

What this takes is an honest stocktake and someone who leads the conversation between the business side and IT to a result. We support you with this second part, for example by preparing the mapping page for your project and facilitating the workshop. The data protection assessment stays with your data protection officer or your legal counsel. If you would like to assess in advance where your customer systems stand, the Reactivation Audit is a good place to start.

Do you know today who in your company gets called when a points balance is wrong?

Frequently asked questions

What is a data ownership mapping for customer programmes? A single page that records, for each data type in a programme, where the data is created, who maintains it, who approves it, who gets called when there are errors and how it gets into the programme. It is in place before the kickoff.

Who should be responsible for customer data in a mid-sized company: IT, marketing or sales? That is decided for each data type: purchase history is often closer to sales, consents closer to marketing and data protection, interfaces with IT. The data flow between the systems needs a named role as well.

Do I need a data governance project before I start a loyalty programme? No. The mapping only clarifies the data your programme needs.

How long does it take to create a data ownership mapping? That depends mainly on the preparation. It takes longer if nobody is responsible for individual data types or if several systems supply the same data. That is exactly the risk you should know about before the budget is approved.

What do we do if nobody wants to take responsibility for a data type? Then you have found a real project risk, and in good time. The decision belongs at management level, because it affects budget and schedule. Two routes are possible: you fill the role and give the person the time they need, or you start without this data type and add it later.

Note: this article describes responsibilities for customer data from the perspective of customer systems and project management. It is not legal advice. For an assessment of your obligations under the GDPR, for example on consent, withdrawal of consent and accountability, please contact your data protection officer or a legal adviser.

Sources

• Zeta Global / Forrester: survey on loyalty data (May 2026)
• Zeta Global: press release on the loyalty data study (2026)
• Regulation (EU) 2016/679 (GDPR), EUR-Lex
• Gartner: prediction on data and analytics governance initiatives (press release of 28 February 2024)
• Gartner: survey of marketing leaders on generative AI (press release of 23 August 2023)