The situation
Fictional planning example. These are sample decisions, not customer results or a demonstration of a live configuration.
Two teams at a fictional business capture the same caller need using different labels. One uses “service type,” while the other uses “request category.” Operations needs a usable common record without losing what the caller actually said.
Sample intake record
Use the distinction between reported information and confirmed outcomes when reviewing your own process.
| Field | Sample entry | How to use it |
|---|---|---|
| Source field | Service type / request category. | Compare definitions before assuming the labels mean the same thing. |
| Caller wording | Caller requests maintenance for existing equipment. | Preserve useful original context alongside any agreed category. |
| Proposed category | Maintenance request. | An illustrative value to review, not an assumed production schema. |
| Missing detail | Equipment identifier not supplied. | Use the agreed unknown representation; do not invent an identifier. |
| Review owner | Operations field-definition owner. | Approve mapping choices and handle ambiguous values. |
Walk through the decisions
- Compare meaning before renaming. Write down what each source field represents, who uses it and whether it combines multiple concepts.
- Agree a common representation. Choose the destination field and allowed values with the owning team. Keep the sample category provisional until approved.
- Preserve uncertainty and provenance. Retain the caller’s relevant wording and mark the absent identifier as unknown. Do not make a record appear independently verified through normalization.
- Review delivery and exceptions. Confirm supported destination behavior, required fields and ownership for rejected or incomplete records before configuring a live handoff.
Example handoff note
Mapping proposal: compare service type and request category for a common request-category field. Sample caller wording retained. Maintenance category proposed for owner review. Equipment identifier unknown. Destination requirements and exception handling still need agreement.
When the routine path does not fit
- The labels have different meanings: Keep separate fields or revise the mapping proposal; do not merge unlike concepts merely because their values overlap.
- A required destination value is missing: Follow the agreed exception path rather than supplying a fabricated default.
- A record may duplicate an existing inquiry: Use the approved review process. A shared category alone does not establish that two records are duplicates.
Use this with your team
Who defines each field? Which values are permitted? How are unknowns represented? Who reviews mapping ambiguity or a record that does not reach its destination?
Replace the fictional choices with your approved process before configuring service. This page does not collect or send your answers.