# CC057 implementation workbook notes

These companion worksheets support “CRM Implementation: Translate Your Sales Process into Fields, Stages and Handoffs”. All businesses, records, amounts, dates and worked scenarios in the worksheets are hypothetical. No implementation or acceptance test has been performed.

## Files and intended use

- CC057-implementation-workbook.csv: 51 worked rows covering scope, data model, stages, exceptions, permissions, privacy, integrations, migration, handoffs, reporting, acceptance tests and phase gates.
- CC057-field-dictionary.csv: 29 worked field definitions. These are proposed implementation requirements, not confirmed features of any vendor or edition.
- The CSVs are editable planning documents. They are not import templates for a production CRM.
- The 29 field definitions are a worked starting set, not a complete deployable schema. Add any remaining fields required by approved rules, such as stage, account links, handoff owner, return reason and correction due date. Keep one stored value per field; examples such as USER-SALES-01 and LOC-A are synthetic identifiers.

Open through your spreadsheet application's text/CSV importer, select UTF-8, use comma as the delimiter and double quotes as the text qualifier. Import identifiers, dates and timestamps as text when you want to preserve their written format. Retain a working spreadsheet copy if you need filters, formatting or extra tabs; those features are not stored in CSV. No spreadsheet formulas or macros are embedded.

Filter the main workbook by record_type. Replace the examples with approved decisions for your business. Retain stable IDs so tests can reference requirements. Add columns for your target dates, environment and configuration version if useful. Record evidence references in approved storage rather than pasting credentials or sensitive customer records into the workbook.

## Main workbook columns

| Column | Practical definition |
| --- | --- |
| id | Stable unique reference for one rule, scenario, test or gate. Keep it when wording changes. |
| record_type | Category for filtering: scope, data_model, stage, stage_exception, permission, privacy, communication, integration, migration, deduplication, handoff, report, test or phase. |
| related_ids | Semicolon-separated references to prerequisite or relevant workbook/field-dictionary rows. This is a relationship list, not an execution order. |
| object_or_process | Record type, system boundary or process affected. |
| rule_or_scenario | Short name of the decision or scenario. |
| precondition_or_input | Starting state or input required before the rule or test applies. |
| steps_or_mapping | Action sequence, field mapping or configuration decision to implement. |
| expected_result | Observable acceptance condition. It does not record a test result. |
| exception_or_failure_path | Behaviour when normal processing cannot proceed, including review, alert or recovery. |
| responsible_role | Role doing or maintaining the work. Replace with actual accountable names where appropriate. |
| approver_role | Role authorized by the business to accept this decision or evidence. |
| required_evidence | What must be captured to support acceptance: record IDs, logs, approvals or reconciliation. |
| priority | Release priority. The examples use must; approve any change against actual release scope. |
| status | hypothetical_example for design rows; not_run for test rows. Use pass, fail or blocked only after actual execution and review. |
| actual_result | Blank initially. Enter what actually happened, including deviations. |
| evidence_reference | Blank initially. Link approved evidence with environment and configuration version. |
| tested_by | Blank initially. Actual person who performed the test, not the intended owner. |
| tested_at | Blank initially. Actual execution timestamp with a time-zone offset. |

## Field dictionary columns

| Column | Practical definition |
| --- | --- |
| id | Stable FD-prefixed reference used by workbook rules and tests. |
| object | Record on which the field belongs. Adapt to the actual CRM's supported model. |
| internal_name | Suggested stable machine-facing name; not a verified vendor API name. |
| label | Plain user-facing field label. |
| data_type | Intended storage type, such as enumeration, identifier, text or timestamp. |
| definition | Meaning of the field, including what it excludes. |
| allowed_values_or_format | Accepted options or representation. Adapt to verified system behaviour. |
| required_point | Stage or condition at which the information must be known. |
| authoritative_source | System or reviewed evidence that controls the value. |
| editable_by | Authorized roles or automation responsible for updates. |
| validation_rule | Observable restriction or consistency check. Test every supported route that can affect it. |
| hypothetical_example | Worked synthetic value. Do not treat it as client data, a benchmark or a completed test. |
| exception_handling | What to do with ambiguity, missing data or unsupported behaviour. |
| data_handling | Access, privacy, retention or reporting considerations to resolve in your business policy. |

## Using the examples safely and accurately

The monthly CAD 1,800 amount and 12-month initial term illustrate a simple CAD 21,600 first-term recurring value. That is not a quote, business result or recognized revenue. Variable pricing, one-time work, tax and renewal need separate definitions.

The 240-row migration example reconciles 222 retained destination contacts, 10 additional source rows merged into retained contacts and 8 held rows. Prove the individual row mappings and relationships; the arithmetic alone is not acceptance evidence.

A signed current proposal is the fictional business's closed-won rule; no deposit is required in that example. Define your own commercial conditions. A returned delivery handoff does not automatically reverse a valid sale.

The article's four-staffed-business-hour assignment rule is illustrative. Set your own staffed calendar, time zone, holidays, escalation and fallback owner. Do not silently convert business hours to elapsed hours.

Communication-basis and suppression fields need review against applicable requirements. The examples do not establish legal eligibility to send messages. Unknown eligibility is not permission. No retention periods are invented here.

A role matrix must be verified against the actual subscription, interfaces and connected systems. If a rule cannot be enforced, document the supported workaround, residual limitation and acceptance owner before release.

## Acceptance and handover

Perform tests in a controlled environment using synthetic records and approved destinations. Fill actual_result, evidence_reference, tested_by and tested_at only after execution. Record blocking defects and retest affected scenarios after correction. An expected result or a design approval is not a passing test.

For each release gate, keep the dated decision and its evidence. At handover assign the business owner, administrator, backup, integration owner and receiving operations owner. Preserve a change log, support boundary, recovery instructions and approved outstanding issues.
