Keep the CRM clean
Maintain saved records and their relationships in the workspace.
Use this guide for a recurring CRM hygiene pass when people, companies, deals, and their next actions need to remain credible to the whole team. CRM is shared operating memory for customer relationships, not a place to make a database look full. Read CRM records for the record model, and use Find out why something failed when an object or run needs a specific diagnosis instead of a normal hygiene decision.
The crm skill teaches Architect to preserve evidence, identity, and human judgment. It reads the relationship before changing it, then places each confirmed fact in the right kind of record history. A clean CRM makes future action safer because a teammate can see who someone is, what happened, what is next, and why a pipeline stage says what it says.
Needs and produces
You need a defined record scope, such as recently created records, suspected duplicate pairs, open deals, or records changed since the last pass. Before a change, inspect each candidate's full name, employer, title, verified work email or profile URL, relationship to a company record, current owner, pipeline stage, expected value when applicable, next step, recent timeline activity, source evidence, and open work.
The result is a readback of records reviewed, relationship purpose, pipeline impact, evidence examined, changes made, and why each change belongs in a field, note, or timeline. It reports two leading hygiene measures: suspected duplicate-pair count and open deals with no activity in 21 or more days. Zero is a reported result, not an assumption made because a list was not inspected.
This guide does not turn every thread or worksheet result into a record. A record represents a real relationship entity with identity evidence and a purpose. For conversation-specific work, start in Inbox. For source rows and qualification evidence, start in Workbooks and worksheets and promote only durable, supported facts.
Read the relationship before changing it
In the Records screen, open the current record and related people, company, timeline, open deals, tasks, and source evidence before proposing an edit. Architect uses the crm skill with CRM reads to search for existing matches by verified email, profile URL, company, name variants, and recent activity. It reads each record again immediately before a mutation because another teammate may have changed it while the pass was in progress.
Separate information by its role. A stable, reusable, queryable fact belongs in a field, such as verified title, lifecycle stage, owner, company domain, explicit qualification, or consent state. A note holds reasoning, uncertainty, meeting detail, and context that is not yet trusted enough for a field. A timeline activity records an event at a time, such as a call, email, meeting, reply, stage change, or completed task. A one-time narrative should not become a permanent field just because it is useful today.
Human-entered values are owned judgment. Do not overwrite one with an enrichment guess. When evidence conflicts, keep both sources and dates visible, identify which field is in conflict, and request resolution when the difference is material. Add a new verified fact only when the available evidence supports it. This lets the CRM retain uncertainty without turning it into a false claim.
Protect identity and provenance
Create a person, company, or deal record deliberately. One record represents one real relationship entity. Link a person to a company only when the evidence supports the connection, and add a source, owner, and next action when they are known. A record without identity evidence or a purpose is a lead-shaped duplicate, not progress.
Merge only when at least two independent signals identify the same entity. The skill gives examples: the same verified work email plus the same profile, the same profile URL plus matching employment, or a confirmed correction from the user. Before any merge, compare the timelines, field provenance, linked records, owner, open work, and deal state. Preserve conflicting claims rather than erasing evidence to make a pair look simpler.
Weak similarity does not establish identity. A shared public email domain, similar company, similar first name, or a guessed enrichment match alone is not enough to combine records. When signals conflict, leave the pair separate and show it for review. That outcome is useful because merging two distinct people or companies can damage both timeline history and the team's future judgment.
Keep pipeline state true
A pipeline is true when every open deal represents active, evidenced customer work: the right person and company, a credible stage, a clear owner, recent activity, and a concrete next step. Value or a late-stage label does not make an inactive deal healthy. Review the relationship context before changing a stage, then record the evidence and next step that support any stage change.
Stages advance because a customer action or documented qualification meets the workspace's stage definition. They do not advance because time passed, enrichment improved, or a forecast would look better. If the stage criteria are unclear, preserve the current stage and propose the decision that remains. This protects the difference between observed customer work and a desired pipeline outcome.
A weekly pass reads recently created records, suspected duplicates, conflicts or stale evidence, open deals without activity in 21 or more days, deals without a next step or owner, and recently changed stages. Fix low-risk evidence-backed field gaps, then read back sampled records and the two headline counts. The sample establishes that the reported changes match the live records rather than only a prepared list.
- 1
Bound the review set
Ask Architect to use thecrmskill for a specific age, ownership, or pipeline scope. In Records, confirm the count and the records included before treating the set as a hygiene result. - 2
Read relationship evidence
Architect reads identity, related records, timeline, source evidence, owner, next step, and open work. Check that each proposed stable fact has evidence and that uncertain reasoning remains a note rather than a field. - 3
Resolve only strong duplicates
Architect compares independent identity signals and preserves conflicts. In the record view, check the timelines, linked records, owner, and deal state before any merge decision is made. - 4
Repair low-risk gaps
Architect updates supported field gaps and records event history in the timeline. Check that human-entered values were not replaced by an enrichment guess and that a stage change carries customer evidence and a next step. - 5
Read back the CRM state
Architect reads changed records and the duplicate-pair and inactive-deal counts. Check the sampled records in Records before reporting the weekly pass complete.
Credits and scope
The skill says CRM reads, duplicate review, and timeline inspection are free and come before enrichment. Enrichment can have a cost, so keep it separate from routine cleanup. When an enrichment is relevant, state the target records, fields sought, expected coverage, current estimate, and how the result will be reviewed. Do not enrich records merely to fill every blank field.
For paid live work, inspect the delivered capability schema and returned estimate, then run under the stated maximum-credit ceiling. The scope should be a list of named records and fields, not an implied expansion from a duplicate search. Finished results and record readbacks establish what changed and what credits were charged. A proposed result is not proof that a field value is now present.
When it goes wrong
If the checks cannot establish identity or intent, return the findings and ask one narrow question. Do not create a speculative record to make the list look complete, and do not merge on a public domain, similar name, company similarity, or a guessed enrichment result. Record the conflicting signals and leave the pair visible for future review.
If an enrichment result conflicts with a human-entered field, do not overwrite the human judgment. Preserve source and date, name the conflict, and request a resolution for material differences. If a record changed between the initial read and the intended update, read it again and re-evaluate the bounded change. A staged update based on stale record state should not be applied blindly.
If a deal appears inactive, inspect its owner, activity, and next step before downgrading a stage. If the requested work is a failing row, send, or automation run rather than a relationship decision, use Find out why something failed. Keep the record link and any run evidence in the report so the next investigation begins from what the team actually sees.
Leading metric and next play
Watch the duplicate-pair count and the count of open deals without activity in 21 or more days. Pair those counts with sampled record readbacks, because a decreasing number is meaningful only when identity evidence, ownership, timeline, and next step remain intact. The completed hygiene pass should say what was reviewed, what was changed, what was left separate, and when the next weekly pass should happen.
Use Weekly review to compare CRM hygiene with live motion, qualification, sequence analytics, and credits. Use Turn replies into meetings when a conversation yields durable relationship evidence that belongs in the CRM record.