Canzuki

Foundation First

What has to be true before a CX platform or AI decision is worth making.

Three questions to answer before the platform conversation begins — before the RFP is drafted, before the shortlist is built, before anyone sits through a demonstration. None of them are technical.

The demonstration is not the problem

Every week a platform promises to transform customer experience. The demonstrations are good, because demonstrations are built to be good. The assistant handles the interaction fluently. The journey is mapped. The figures quoted for handle time and satisfaction are the figures the vendor has seen somewhere, in an organisation that may look nothing like yours.

None of that is dishonest. It is simply answering a question you did not ask. The demonstration shows what the platform can do. It says nothing about what it will do in your organisation, on your data, across your boundaries, with your business rules.

Human employees compensate every day for disconnected systems, conflicting data and processes that exist only in people’s heads. Automation doesn’t have that luxury.

The point of this

AI does not fix operational chaos. It executes it faster, more consistently, and at a scale no human team could reach.

The three foundations

01

Organisational alignment

Do your teams share data, or do they hold it?

Every function has a boundary around its data. Under normal conditions those boundaries cause friction and people absorb it — an agent opens four applications and copies an account number from one screen to another. It is inefficient and it works. Automation meets every one of those boundaries at once, and it cannot improvise.

A customer query crosses from Operations into Finance and IT, and stops at the boundaries that will not open. Operations Finance IT Resolution Owns the customer Owns the billing data Owns identity Never reached
A customer query passes through Operations, then stops at the Finance and IT boundaries, never reaching resolution. Operations Owns the customer The query starts here Finance Owns the billing data Will not open the interface IT Owns identity Will not open the interface Resolution Never reached
Operations can reach the customer. Finance owns the billing data and IT owns identity, and neither boundary opens.

An illustration — the assistant that cannot see

A voice assistant is deployed to handle billing enquiries. Customer Service owns the relationship. The data needed to resolve a dispute sits in an ERP governed by Finance. The authentication logs that would confirm who is calling belong to IT. There is no cross-functional data governance, so the assistant can reach neither. It becomes a spoken FAQ: it can see there is a billing question, cannot look at the account, and transfers the customer to somebody who can. The organisation has bought a platform and added a step.

What to do before the RFP

Map what the automation has to touch

Put Operations, IT, Finance and Legal in one room and define precisely which systems have to be reached to resolve a query end to end.

Establish data stewardship

Move from departmental ownership to shared governance. Where a function will not open an interface, that use case is not viable and should be shelved before software is bought, not after.

02

Data integrity

Do your systems tell a consistent, verifiable truth about your customer?

Most organisations run on quiet manual correction: spreadsheets that reconcile two systems nobody has integrated, rules experienced staff apply without being asked, knowledge about which record to believe when two disagree. These corrections are invisible from the executive floor, because they work. Automation removes all of them at once.

A source of truth grid: four customer entities against three systems. Account status is claimed by two systems at once. CRM Billing Ticketing Identity Account status Balance Contact details Filled = this system holds the master record.
A source of truth grid. Account status and contact details are each claimed by two systems at once. Who holds the master record Identity CRM Billing Ticketing Account status CRM Billing Ticketing Balance CRM Billing Ticketing Contact details CRM Billing Ticketing Filled = this system holds the master record. Two claims on one row is a finding.
Where two systems both claim the master record, the automation has no way to choose between them.

An illustration — the confident wrong answer

A long-standing customer calls. The CRM shows the account active with a negotiated arrangement in the relationship history. Billing shows it suspended after an overnight batch failed. The address changed last week; the CRM has the new one and billing does not, because the sync failed without raising an error. The automation queries both, finds a conflict it has no rule for, and does what it was built to do — it defaults to billing. A customer who has not missed a payment in five years is told the account is suspended, then transferred to an agent who receives none of that context.

The platform worked exactly as designed. The data underneath it did not.

What to do before the RFP

Audit the source of truth

List the entities that matter — identity, account status, balance, contact details, recent interactions — and document which system holds the master record for each. Where two systems both claim it, that is a finding.

Fix the integration, not the interpretation

No platform cleans data in flight, whatever is implied. Require real-time integration that reconciles records before automation reads them, and treat any claim to resolve conflicts at runtime as something to be tested rather than believed.

03

Systems clarity

Do you know how your operation actually works?

Business rules decide who gets priority, how a refund is calculated, when an account is held for review. They live in three places: configured in a system, carried in the heads of experienced staff, or nowhere at all. The rules that live nowhere are the ones automation will inherit without anyone deciding that it should.

Business rules live in systems, in people's heads, and nowhere at all. Automation inherits only the first. In the system In people’s heads Nowhere at all What the automation inherits
Rules live in the system, in people's heads, or nowhere. Only the configured ones are inherited by the automation. In the system In people’s heads Nowhere at all What the automation inherits
Only the configured rules are inherited. The discretion your best agents apply is left behind.

An illustration — the rule nobody wrote down

An airline contact centre automates cancellations. Over several years the frontline has adopted an informal practice: where a customer is reasonable and has been with the airline for some years, the processing fee is waived. It is in no handbook and no system. The automation reads the configured rules correctly and applies the fee to everybody. Long-standing customers who have never been charged it before are charged it now. Complaints rise, escalations follow, and the platform is blamed for being rigid when it has done nothing except execute the only rules it was given.

What to do before the RFP

Find the workflows nobody documented

Sit with your strongest agents. Record what they do, not what the training material says they should do. The gap between the two is the material.

Standardise before you automate

A rule that cannot be expressed as a clean conditional is not ready to be automated. Resolve the logic on paper first, and decide deliberately which discretion you intend to keep.

Reframing the RFP

Stop asking what the platform can do.

A feature-driven RFP produces a shortlist in which every vendor has ticked every box, because every serious vendor can. The questions worth asking are the ones that can only be answered about your organisation.

Don’t just askAsk
Does your platform support omnichannel data integration? Here is a map of our CRM, billing and ticketing systems and the conflicts we have already found between them. Detail how your platform resolves those conflicts in real time.
Can your AI agent handle complex business logic? We have documented the business rules we hold in systems, and we know others exist only as practice. What discovery process and tooling does your implementation team use to surface and normalise them before go-live?
What is the deployment timeline? Given the attached data integrity findings, what must our internal teams complete before your platform can be deployed without driving escalation rates up?
What changes

The first set of questions tells you what a vendor sells. The second tells you what they will have to deal with, and how honest they are prepared to be about it before the contract is signed.

See the full eight-question checklist →

Take it away with you

Foundation First, as an ebook.

The whole argument in one document: the three foundations, a worked example of how each one fails in practice, the risks that follow, and what to do before the RFP is drafted. Written to be circulated to the people who will have to live with the decision.

We’ll email you the PDF and, from time to time, an article on CX foundations and contact centre technology. Nothing else, no sales sequence, and you can unsubscribe from any of them.

The engagement

Start here.

Most Canzuki relationships begin with Foundation First. It is a defined, fixed-price assessment rather than an open-ended consulting exercise. The boundary, deliverables, timing and acceptance criteria are agreed before work begins, and Canzuki carries the risk of the work taking longer than expected within that boundary.

The assessment brings together the people who understand the customer, the operation, the technology and the commercial decision.

What you leave with

A Foundation First findings report

A concise view of the current position and the issues that matter.

A prioritised readiness gap assessment

What needs attention before procurement or implementation — and what doesn’t.

Clear ownership

Which issues belong to Operations, Technology, Data, Finance, Governance or another part of the organisation.

A decision path

Proceed, remediate first, change scope, challenge the proposed approach — or stop.

Sometimes the answer is not a new platform

Our role isn’t to justify a procurement exercise. It is to improve the decision. That may mean proceeding to market, changing the scope, fixing data or operating-model problems first, or extending an existing platform rather than replacing it. Occasionally it means: don’t buy anything yet. That is why independence matters.