CRM Cleanup Automation Prompt

Develop a production-ready CRM cleanup and automation specification using the following inputs.

Required inputs:
- CRM platform and cleanup scope: [CRM platform and cleanup scope]
- Cleanup objectives and acceptance thresholds: [Cleanup objectives and acceptance thresholds]
- Data dictionary and lifecycle rules: [Data dictionary and lifecycle rules]
- Data profile, exports, or representative sample records: [Data profile and sample records]
- Duplicate matching and merge policy: [Duplicate matching and merge policy]
- Retention, privacy, and compliance constraints: [Retention privacy and compliance constraints]

Useful operational context:
- Automation capabilities, integrations, and synchronization paths: [Automation capabilities and integration map]
- Approval owners, maintenance window, and rollback authority: [Approval owners and change window]

Input handling:
1. Confirm the CRM objects in scope, record volumes, immutable identifiers, source systems, systems of record, synchronization direction, and applicable business units.
2. Treat the data dictionary, approved lifecycle definitions, retention policy, consent records, and supplied CRM evidence as authoritative only within their stated scope. Separate supplied facts, observed data patterns, assumptions, hypotheses, conflicts, and unknowns.
3. Ask concise clarification questions if a missing input prevents safe decisions about merging, deletion, consent, retention, lifecycle changes, or rollback. Otherwise, continue with a bounded draft, identify the missing evidence, and mark affected recommendations as unverified or blocked.
4. Never invent field values, platform capabilities, record counts, test results, approvals, or execution evidence. If samples are incomplete or nonrepresentative, state that limitation before estimating impact.

Analysis and design workflow:
1. Establish a baseline inventory by object and field. Report record counts when supplied; null and invalid-value rates; malformed dates, emails, phone numbers, and identifiers; orphaned relationships; conflicting source values; impossible lifecycle combinations; stale-record candidates; and duplicate candidates. Show the query, filter, export column, report, or sample evidence behind each finding when available.
2. Define normalization rules before duplicate matching. Cover casing, whitespace, punctuation, phone country codes, email normalization, company suffixes, addresses, Unicode, aliases, and intentionally shared contact details. Preserve raw values or an auditable before-state where required.
3. Design duplicate detection separately for each object. Specify candidate-generation keys, exact and fuzzy comparisons, field weights, thresholds, exclusions, confidence bands, and manual-review zones. Address false-positive and false-negative trade-offs, parent-child records, cross-business-unit collisions, person-versus-company ambiguity, and records created by integrations.
4. Define merge and survivorship behavior. Identify the winning record and field-level source precedence; preserve immutable and external IDs, ownership, consent and lawful-basis data, activities, notes, attachments, campaign membership, opportunities, cases, relationships, and audit history. If the CRM cannot safely merge an artifact, specify quarantine, relinking, or manual handling instead.
5. Define missing-field and invalid-value treatment by field. Distinguish values that may be standardized, values that may be backfilled from an approved source, values requiring owner review, and values that must remain unknown. Do not infer or fabricate personal, consent, financial, or contractual data merely to satisfy completeness rules.
6. Define stale-record policy using explicit inactivity signals and time windows. Exclude or separately review records subject to legal hold, retention requirements, active opportunities, open support cases, active subscriptions, recent engagement, unresolved consent status, or downstream dependencies. Compare suppression, archive, quarantine, and deletion; recommend deletion only when policy, authority, recovery, and dependency checks support it.
7. Reconcile lifecycle stages and statuses against approved entry, exit, regression, and terminal-state rules. Detect contradictory stages, skipped prerequisites, reopened records, stale timestamps, and automation-created loops. Define the evidence required for each correction and how synchronized systems could overwrite it.
8. Convert approved cleanup logic into an automation design. For every rule, specify trigger, scope filter, exclusions, precedence, action, idempotency key or rerun behavior, batch size, rate-limit handling, retry policy, error queue, audit fields, notifications, and integration side effects. Identify race conditions, recursion, workflow conflicts, and ordering dependencies.
9. Create a controlled rollout: read-only profiling, versioned rule review, snapshot or recoverable backup, sandbox test, dry run, reviewer sampling, canary batch, reconciliation, staged production batches, monitoring, and rollback. Include stop conditions for unexpected match rates, relationship loss, consent changes, excessive errors, sync divergence, or metrics outside approved thresholds.
10. Require named human authorization before enabling workflows, merging records, bulk updating lifecycle stages, archiving, deleting, or changing retention and consent data. ChatGPT may analyze supplied material and draft rules, queries, pseudocode, test cases, and implementation instructions; it cannot access the CRM, execute changes, verify live results, or grant approval unless independently supplied evidence demonstrates those events.

Required deliverable:
A. Scope and evidence ledger
- CRM objects, systems, volumes, sources of truth, assumptions, unknowns, conflicts, and blocking gaps.
- For each material assertion: evidence source, observation, confidence, and limitation.

B. Data-quality baseline
- Table with object, issue class, detection rule, affected count or unavailable status, denominator, rate, severity, sample evidence, and business impact.

C. Cleanup rule catalog
- Table with rule ID, object, issue, eligibility condition, exclusions, action, source precedence, confidence threshold, review requirement, downstream effects, reversibility, and owner.
- Include dedicated subsections for duplicates and survivorship, missing or invalid values, stale records, and lifecycle-stage reconciliation.

D. Automation specification
- Table with rule ID, platform mechanism, trigger or schedule, dependencies, processing order, idempotency behavior, batch and rate limits, retry handling, exception queue, audit logging, alerts, and disable control.
- Use platform-neutral pseudocode when platform syntax or capabilities are not evidenced. Label any platform-specific configuration as proposed until confirmed.

E. Safety, approval, and recovery plan
- Data minimization and access controls; redaction of secrets and unnecessary personal data; backup or snapshot requirement; sandbox and dry-run controls; protected-record exclusions; approval gates; stop conditions; rollback steps; and post-rollback reconciliation.

F. Verification matrix
- For every cleanup rule, provide test case, representative input, expected observation, actual observation or not executed, evidence location, pass threshold, and status.
- Include tests for duplicate precision and recall using a reviewed sample, false merges, missed duplicates, survivorship, relationship preservation, required-field validity, lifecycle transition validity, stale-record exclusions, consent preservation, automation reruns, retries, rollback, integration reconciliation, and audit-log completeness.
- Quantify acceptance criteria from the supplied thresholds. If no threshold is authorized, propose one with rationale and mark it pending approval.

G. Rollout and handoff
- Ordered implementation batches, responsible owner, required approval, monitoring metric, decision checkpoint, rollback trigger, unresolved issues, and the smallest safe next action.

Status and claim rules:
- Label each item as proposed, awaiting evidence, blocked, approved based on supplied evidence, executed based on supplied evidence, verified based on supplied evidence, or unresolved.
- Do not claim that records were cleaned, merged, deleted, tested, approved, deployed, or verified unless the corresponding action occurred and supporting evidence was provided. Keep recommendations and expected outcomes distinct from observed results.