How this moved to the top of your agenda

• How did this problem first surface in your organization?
• Walk me through the last time a duplicate customer in your reports caused a material error
• When that incident happened, who was pushing hardest for a fix Options: Data team, Finance/FP&A, Mergers and acquisitions team, Risk and compliance, Operations, Other
• What immediate outcome are you hoping a first phase will deliver within 8 weeks? Options: Clear de-duplicated revenue for reporting, Single view for a regulatory filing, Reduced reconciliation work for analysts, Faster customer onboarding in one system, Other
• Which stakeholder groups must see a quick win for the project to keep momentum Options: Revenue reporting/FP&A, Customer success and sales ops, Compliance and risk, CRM owners, IT and data engineering, Legal, Other

Where the single-customer view actually breaks

• If an auditor asked tomorrow for a single-customer exposure file, what gap would make you fail that request?
• Describe the most common identity variations you see across systems, for example differences in legal name, address, or corporate hierarchy Options: Name variations, Address inconsistencies, Corporate hierarchy differences, Multiple internal IDs, Missing tax or legal identifiers, Other
• How many systems currently hold customer records for the entity domain you plan to pilot Options: 1-3 systems, 4-6 systems, 7-10 systems, 11-20 systems, 20+ systems
• On average, how many duplicate records does a typical customer have across those systems
• What single mismatch type, if left unresolved, would make the golden records unusable for reporting or compliance

Who signs off and who will block progress

• Who in your organization has final sign off on master record definitions and data changes Options: CDAO or Head of Data, VP Data Management, Head of BI or Reporting, CFO, Legal or Compliance, Other
• Please list the teams that will need to approve data access or schema changes during the pilot
• Which person or role is expected to own day to day reconciliation once golden records are produced Options: Data steward, System owner, Application manager, Business process owner, Analytics lead, Other
• Tell me about any system owners who have previously resisted centralized data control and why
• If the system owners refuse to enable writes back to their applications, what happens to the pilot timeline

What a fast, convincing win actually looks like

• Name one concrete metric that would make your executive team call the pilot an immediate win
• Minimum number of records that must be validated before your business will stop manual verification
• Would reducing duplicate driven revenue variance by a material amount be enough for the board to approve expansion, and if so what percent reduction qualifies Options: >=30% reduction, 20-30% reduction, 10-20% reduction, <10% reduction, Unsure
• Describe the business process that will consume the golden records first, and who in that workflow will be the primary user
• List the approvals or budget steps that would remain if the pilot meets its targets

Where technical and political risks live

• Identify the single technical limitation that would force you to pause or stop a phased deployment
• Are the source systems' data and APIs accessible for an evaluation load, or will we need scheduled exports or direct extracts Options: APIs available for all sources, APIs available for some sources, Scheduled exports only, Direct database access required, Unknown
• Who currently owns the connectors or integration work, and can that group grant test credentials in a sandbox Options: Internal IT, Vendor managed, Business unit team, No clear owner
• Are there regulatory constraints, such as data residency or masking rules, that could extend the timeline Options: Yes, significant constraints, Yes, minor constraints, No known constraints, Unsure
• Name the outcome from a legal or compliance review that would stop the project immediately

Other routes you are weighing

• Tell me which alternatives you are actively evaluating right now, including internal rebuilds or staying with current processes Options: Commercial MDM vendor, ERP or CRM native deduplication, Homegrown scripts in the data warehouse, Manual spreadsheets and reconciliation, Consulting led redesign, No alternatives evaluated, Other
• Under what specific conditions would you choose to stay with the current approach instead of moving to a vendor
• Has anyone on your team proposed building this internally, and if so is there a published plan or timeline Options: Yes, internal plan with timeline, Yes, high level proposal only, No internal proposal, Unsure
• State the proof point that would make you stop evaluating other vendors and commit to a single pilot this quarter

Practical readiness for a pilot

• Imagine we asked to load 100,000 customer rows this week, which integration or permission would fail first
• Do your source systems offer API endpoints for the data we need, or do they require scheduled exports Options: APIs available for all sources, APIs for some sources, Scheduled exports only, Direct DB extracts required, Not sure
• Provide the owner for each source system and indicate whether they can commit to a test window within the next 30 days
• Do export or masking rules prevent sharing PII to a vendor during evaluation Options: Yes, cannot share PII, Yes, but can share with masking, No, can share with contract, Unsure
• State the absolute readiness gap that would force you to delay the pilot more than 8 weeks

Designing the pilot and acceptance criteria

• Specify the acceptance threshold for match precision and recall that would make the business trust the golden records without manual review
• Explain the sampling approach you would accept to surface edge cases like subsidiaries, account family trees, and anonymized records
• Identify the fields that are non negotiable for match rules, for example legal name, tax ID, or parent account Options: Legal name, Tax ID, Address, Phone or email, Parent company, Account number, Custom identifier, Other
• Will you require human review steps in the merge workflow, and if so what throughput do you need from reviewers per day Options: Yes, required with SLA, No, fully automated, Some manual review with target throughput
• Specify the reconciliation rules that must be captured before any write backs are allowed
• Should the pilot meet acceptance criteria but a source system owner refuse writes, would you accept read only golden records or is that a deal breaker Options: Accept read only for initial phases, Deal breaker, need write capability, Depends on the system, Unsure
• Select the minimum acceptable match precision for the pilot Options: >=95%, 90-95%, 85-90%, <85%, Unsure

How decisions will be made and next steps

• Point to the role with budget authority to approve expansion after the pilot
• Estimate how quickly procurement can sign a pilot statement of work once legal has approved terms Options: Within 1 week, 1-2 weeks, 2-4 weeks, Longer than a month, Unsure
• Provide your preferred deployment window, such as a month or quarter, when system owners allow schema changes
• Should the pilot be proven in 4 weeks, which internal process will allow you to purchase and schedule phase 1 within the next 30 days
• Choose the procurement or contracting model you prefer Options: Standard purchase order, Master subscription agreement, Time and materials SOW, Pilot with conversion clause, Unsure

Final reflections and potential blockers

• Point to the organizational priority that, if elevated, would push this project off the calendar
• Have you estimated the cost of poor identity, for example overstated revenue, duplicate support work, or regulatory fines Options: Yes, we have quantified costs, We have qualitative estimates, No formal estimate exists, Unsure
• Please supply the names and roles we should include in a three week pilot steering group
• Would you proceed with a proof of concept if a data owner cannot be committed to the pilot Options: Yes, with mitigations, No, need committed data owner, Maybe, depending on scope, Unsure
• When are you ready to start a pilot Options: Immediately, Within 2 weeks, Within 1 month, In 2-3 months, Need internal approval first

• Solution Experience: Trusted Golden Records

• Confirm the current state and its cost
• Customer confirms the demonstrated match-and-merge workflow eliminates the duplicate-driven revenue misstatement and reduces manual reconciliation.
• Provide a representative 100,000-record extract from the two highest-priority source systems for evaluation.
• Customer validates that a phase-1 rollout focused on one entity and one system pair can deliver measurable value within weeks.
• Show match-and-merge on your scenario
• Run match-and-merge on the provided sample and deliver an accuracy comparison against the agreed acceptance criteria within five business days.
• Agreement on the remaining evidence and access required to finalize commercial and deployment commitments.
• Walk through a phased rollout plan for your constraints
• Draft a phase-1 deployment plan that lists source system owners, required data access, migration windows, and expected milestones for sign-off.
• Validate acceptance criteria and trust
• Identify the validation stakeholders and define the specific acceptance checks they will perform during the match-and-merge evaluation.
• Confirm this matches what you meant when you said you needed accurate golden records without manual verification

• Solution Experience: Trusted Golden Records
• Solution Experience Deck
• Solution Brief

• meeting
• slides
• document

• Onboard Source System Connector
• Ingest and Normalize Source Records
• Configure Golden Record Schema
• Configure Match Rules and Thresholds
• Configure Survivorship and Merge Policies
• Run Match-and-Merge to Create Golden Records
• Enable Stewardship Workbench for Manual Resolution
• Implement Record-Level Audit and Lineage Logging
• Deploy Bidirectional Synchronization to Target Systems
• Backpopulate Cleansed Golden Records to Source Systems
• Schedule Incremental Delta Ingestion and Sync
• Export Golden Records to Reporting and BI
• Set Role-Based Access Controls and Permissions
• Enable Phased Single-Entity Deployment

Onboard Source System Connector

• Which source system connectors do you require for phase-1 (specify your two CRM exports, billing database, or file shares)? Options: CRM export, Billing/ERP DB, Marketing automation export, Data warehouse / lake, Flat file share (SFTP), Other
• How many distinct source endpoints will you onboard in phase-1 (count each CRM instance, ERP instance, and file share separately)? Options: 1-2, 3-5, 6-10, More than 10
• Who is the technical owner for each source connector (list owner name, team, and contact for the CRM instance and the billing DB)?
• What authentication methods do your source endpoints support for connector access (OAuth2, JDBC, service account key, basic auth, SFTP key)? Options: OAuth2 / OIDC, JDBC/ODBC with credentials, Service account key, Basic auth, SFTP key/pair, Other
• Describe any network constraints for connector access to your CRM or ERP (IP allowlist, private peering, VPN, proxy, firewall rules).
• Are there legal or compliance approvals required to extract personally identifiable information (PII) from the CRM or customer ledger? Options: Yes, No

Ingest and Normalize Source Records

• Which file formats will you ingest from your current CRM and billing exports (CSV, JSON, XML, database dump)? Options: CSV, JSON, XML, Database export (CSV/SQL), Avro/Parquet, Other
• How many records will the initial ingest include for the evaluation and phase-1 (refer to the 100,000-record sample used in pre-demo)? Options: Less than 10,000, 10,000-100,000, 100,000-500,000, More than 500,000
• What normalization transformations are required on ingest for customer data (name parsing and canonicalization, address normalization to postal standard, tax ID formatting)?
• Specify the historical backfill and incremental delta strategy for your CRM and billing systems (full backfill then daily delta, backfill only, incremental only). Options: Full backfill once then daily delta, Backfill then hourly delta, Incremental only (no backfill), Custom schedule
• Identify the primary data quality issues discovered during pre-discovery that require cleansing (examples: missing postal codes, duplicate account numbers, inconsistent currency codes).
• Are there regulated fields that must be redacted or encrypted on ingest (for example national identifiers, protected health information, or payment card details)? Options: Yes, No

Configure Golden Record Schema

• Which entity domain are you deploying in phase-1 for the golden record (Customer, Product, Supplier, Account)? Options: Customer, Product, Supplier, Account
• What primary identifiers must each golden record contain for reconciliation and lookup (customer account number, tax ID, global ultimate ID)?
• List the canonical contact and address fields required by downstream finance and analytics for revenue aggregation (street, city, country, email, phone, legal entity name).
• Specify validation rules for critical fields used in regulatory reporting or revenue roll-up (tax ID format, valid currency codes, required legal entity classification).
• Do you require industry-specific golden-record attributes for this entity (for example KYC status for financial services or National Provider Identifier for healthcare)? Options: Yes, No
• Who will approve the final golden record schema in your governance process (provide role or committee name responsible for schema sign-off)?

Configure Match Rules and Thresholds

• Which matching keys should be included as primary match criteria for customers (email, phone, tax ID, account number, legal entity name)? Options: Email, Phone, Tax ID / EIN, Account number, Legal entity name, Postal address
• How conservative should probabilistic matching be on your evaluation sample to avoid false merges for revenue-bearing accounts (conservative, balanced, aggressive)? Options: Conservative (high precision), Balanced (precision/recall trade), Aggressive (high recall)
• Provide domain-specific matching rules we should encode for post-merger name variations and DBAs (example: strip common suffixes, normalize 'Inc' and 'LLC', recognize legacy merger name mappings).
• Specify the confidence threshold that triggers automatic merge versus routing to steward review for matches impacting revenue reconciliation. Options: Auto-merge at >99% confidence, Auto-merge at >98% confidence, Auto-merge at >95% confidence, Always send to steward review
• Who in your data governance or finance organization owns approval of match rules and thresholds (provide role or name)?
• Are there regulatory or line-of-business constraints on matching that prohibit linking records across regulated silos (for example mortgage versus brokerage client records)? Options: Yes, No

Configure Survivorship and Merge Policies

• Which source should be preferred for survivorship on specific fields (for example billing DB for legal address, CRM for contact email)?
• How should you reconcile conflicting financial or currency fields in the golden record (latest timestamp wins, source priority, aggregate by business unit)? Options: Latest timestamp, Source priority list, Aggregate values, Manual steward decision
• Specify any field-level rules that require manual steward approval before applying survivorship for high-value customer accounts (example: tax ID changes).
• Do you require provenance metadata for every survived value (store source system, source record ID, and timestamp with the field)? Options: Yes, No
• Who will act as steward to resolve merge conflicts for accounts that drive revenue reporting (role or team)?
• Are there fields that must never be merged across legal entities or subsidiaries (for example customer IDs tied to separate regulatory entities)? Options: Yes, No

Run Match-and-Merge to Create Golden Records

• Which specific 100,000-record sample from your two source systems will we use for the match-and-merge evaluation (give export file names, dataset IDs, or query used)?
• What target golden-record accuracy will demonstrate evaluation success for analyst trust (for example specify percent precision and recall thresholds or <1% false merges on revenue-bearing accounts)? Options: Enter custom accuracy target (percent), Use evaluation benchmark from pre-discovery
• How will you measure accuracy for the revenue reconciliation use case (describe the comparison report or BI dashboard to compare aggregated revenue by golden account versus source ledgers)?
• Who will validate the golden-record sample for business correctness during evaluation (name the lead business analyst, finance reconciliation owner, or data steward)?
• State the cadence and time window for evaluation runs on the sample (one-off run, weekly runs for two weeks, or daily runs for a short period)? Options: One-off run, Weekly for 2 weeks, Daily for 3 consecutive days, Custom cadence
• Are there performance SLAs for match-and-merge runs on the 100k sample (maximum wall-clock run time target, for example under 2 hours)? Options: Yes, No

Enable Stewardship Workbench for Manual Resolution

• Which stewardship queues do you need initially (examples: high-value revenue accounts, uncertain merges, address verification)? Options: High-value revenue accounts, Uncertain merges, Address verification, Regulatory exceptions, Custom queue
• How many steward users will need concurrent access to the stewardship workbench during phase-1? Options: 1-3, 4-10, 11-25, More than 25
• What resolution SLA should stewards follow for items in each queue (for example 2 business days for high-priority revenue items)? Options: 24 hours, 2 business days, 5 business days, Custom SLA
• Do you require an auditable comment trail and action log for each stewardship decision for regulator review? Options: Yes, No
• Who will create runbooks and training materials for steward users to resolve common merge/conflict patterns?
• Should the workbench surface suggested merges with confidence scores and field-level diffs for steward review? Options: Yes, No

Implement Record-Level Audit and Lineage Logging

• Which fields and events must be captured in the audit for every golden record change (for example field-level before/after, user, timestamp, and source record ID)?
• What retention period is required for audit logs to satisfy regulatory requirements in your industry (for example 7 years for financial records)? Options: 1 year, 3 years, 7 years, Custom retention period
• Which audit export destinations are required for your compliance tooling (SIEM, secure data lake bucket, compliance archive)? Options: SIEM, Data lake / S3, Compliance archive, Third-party governance tool, Other
• Do you require non-repudiable or write-once logs for audit evidence (for example WORM storage for regulatory submissions)? Options: Yes, No
• Who will review audit reports for suspicious merges or anomalous stewardship activity (role or team)?
• Are there latency constraints on lineage queries used by analytics or the finance reconciliation dashboard (maximum acceptable query latency in seconds)? Options: Under 1 second, 1-5 seconds, 5-30 seconds, Custom

Deploy Bidirectional Synchronization to Target Systems

• Which target systems must receive golden records via bidirectional synchronization in phase-1 (name the CRM instance, billing ledger, and reporting warehouse targets)?
• What synchronization cadence does each target require (real-time push, near-real-time streaming, or daily batch)? Options: Real-time / streaming, Near-real-time (minutes), Daily batch, Custom cadence
• Specify the inbound conflict policy for updates coming from targets back into the hub (last-writer-wins, source-authority list, or route to steward review). Options: Last-writer-wins, Source authority list, Route to steward review, Custom policy
• What acceptance SLA will confirm synchronization readiness for go-live (for example 99.9% record delivery within 15 minutes to named CRM instance)? Options: Enter custom SLA target, Use benchmark from evaluation
• Who will maintain API credentials or service accounts for each synchronization target (provide role or owner)?
• Are there per-target rate limits or maximum payload constraints for API writes we should design around? Options: Yes, No

Backpopulate Cleansed Golden Records to Source Systems

• Which source systems will accept backpopulated cleansed golden records in phase-1 (list CRM instance, billing DB, and any downstream application endpoints)?
• What percentage of records must be successfully written back to pass migration acceptance (for example 95% successful writes with exceptions logged)? Options: Enter custom success percentage, Use evaluation benchmark
• Which rollback or compensation strategy should be used if backpopulate introduces integrity issues (transactional rollback, compensation job, or manual restore procedure)? Options: Transactional rollback, Compensation job, Manual restore, Other
• Who will sign off on completing backpopulate to live source systems (provide role responsible for final approval)?
• Should backpopulate update only non-authoritative fields or overwrite source fields designated as survived by the golden record policy? Options: Update non-authoritative fields only, Overwrite survived fields per policy, Custom per-field rules
• Do your source systems support idempotent write operations to allow safe retries of backpopulate jobs? Options: Yes, No

• desired_state
• current_state
• stakeholders
• gaps
• success_criteria
• decision_readiness
• desired_state
• decision_readiness
• current_state
• success_criteria
• gaps
• stakeholders
• desired_state
• success_criteria
• stakeholders
• gaps
• current_state
• decision_readiness
• decision_readiness
• decision_readiness
• decision_readiness
• decision_readiness

• Master Services Agreement (MSA)
• Statement of Work (SOW)
• Subscription Agreement / Order Form
• Data Processing Agreement (DPA)
• Data Access Authorization
• Deployment Acceptance Certificate
• Service Level Agreement (SLA)
• Change Order Agreement
• Payment Schedule Agreement
• Termination and Data Return Addendum
• Regulatory & Compliance Addendum (conditional)

• Go-live Health Check (weeks 1-4)
• First Measurement Review (weeks 4-10)
• Acceptance Gate Review (around day 90)
• Operational Quarterly Success Review
• Annual Realization and Trust Review

• Prioritize the top reconciliation exceptions and schedule remediation sprints with verification checkpoints.
• Publish the acceptance decision and the signed acceptance record or buyer documented go/no-go as required by the engagement.
• If remediation is required, list the remediation tasks with verification criteria and target completion dates.
• Execute the incumbent wind-down steps, including archiving migrated data and disabling write access where agreed.
• Trend review for core metrics
• Confirm the trajectory of CRM data completeness rate and rep adoption rate and identify any metric areas needing intervention.
• Reduce the reconciliation backlog by agreeing the prioritized remediation items for the quarter.
• Agree the operational verification steps and cadence for the next quarter.
• Re-confirm success criteria and ownership
• Adjust monitoring thresholds and alerting for the identified drift scenarios.
• Publish the prioritized operational backlog items and the planned delivery quarter.
• Year-to-date outcomes against targets
• Confirm whether annual performance for CRM data completeness rate and rep adoption rate meets the expectations recorded in Match & Merge Evaluation.
• Document the current trust level using reconciliation rate and downstream incident count, and decide on any governance follow-up work.
• Agree the long-term monitoring cadence and the format of the annual trust report.
• Publish the annual trust report including metric trends and reconciliation statistics.
• Create a plan to close any remaining stewardship or governance gaps with target dates.
• Set up recurring dashboard alerts and executive summaries for the agreed monitoring cadence.
• Confirm the deployment checklist is complete or enumerate the outstanding items that prevent it being complete.
• Identify the top 3 production issues requiring remediation within the next 14 days.
• Agree the immediate monitoring and alerting improvements needed to detect regressions.
• Publish the go-live issue log with resolution target dates and circulate to the operations forum.
• Enable or tune production alerts for connector failures and reconciliation exceptions.
• Deliver a short training pulse to the initial user cohort and collect readiness feedback within 7 days.
• Present first measurement data
• Decide whether CRM data completeness rate and rep adoption rate are moving toward the acceptance targets recorded in Match & Merge Evaluation.
• Agree specific remediation tasks for each root cause and commit to dates for verification runs.
• Confirm the date and data set that will be used for the acceptance gate evaluation.
• Run a focused data remediation job for fields failing completeness thresholds and report improved completeness rates.
• Execute a match-and-merge tuning batch and publish before/after golden-record precision results.
• Schedule the acceptance gate meeting and finalize the sample extraction criteria documented in Match & Merge Evaluation.
• Restate acceptance criteria and targets
• Produce a documented pass or fail decision for each numeric acceptance criterion recorded in Match & Merge Evaluation.
• If any criterion failed, agree a concrete remediation plan with verification dates.
• Confirm the incumbent system is being retired or formally retained-read-only and record the archival plan.
• Production exceptions and reconciliation summary
• Trust indicators and downstream impact
• Present outcome data against each criterion
• Diagnose gaps and root causes
• Deployment and migration validation
• Enhancement and operations backlog review
• Document pass or fail per criterion
• Governance and data stewardship health
• Agree corrective actions and dates
• Early adoption signals and usage patterns
• Document remaining gaps and long-term monitoring plan
• Blockers and open issues
• Confirm readiness timeline to acceptance gate
• Agree next quarter operations plan
• Incumbent system wind-down checkpoint
• Agree immediate remediation actions
• Agree remediation plan for failed items