Many software disagreements begin with familiar words. Order, customer, site and complete can mean different things to different teams. A small data dictionary makes those meanings explicit before they become fields, status labels and reports. It is a practical conversation aid, not an invitation to model every noun in the business.
Start with the terms people dispute
A hypothetical Orange service business may call the person making a booking the customer, while the accounts coordinator uses customer for the organisation receiving the invoice. Both usages make sense in context, but a single undefined field can confuse them. Identify the terms that affect decisions or handovers. Write a plain-language meaning, an example and, when useful, a counterexample. Keep related concepts separate when staff need to distinguish them in actual work.
Define status by evidence
A status such as complete should say what has happened. Does it mean the work is physically finished, reviewed by a supervisor or acknowledged by the customer? List the evidence that allows a record to enter that state and what work remains afterwards. Avoid using one label for several milestones merely because staff currently communicate the difference verbally. Clear meanings make acceptance criteria and reporting discussions more concrete, even before any database design is considered.
Include units and formats where meaningful
A quantity field is incomplete without knowing whether it represents items, boxes or hours. A requested date may mean arrival, dispatch or completion. Describe those meanings and any known variations. The tradeoff is between clarity and an unwieldy reference document. Focus first on terms that cross team boundaries or drive calculations and decisions. Routine labels that everyone already understands can wait until a real ambiguity appears, rather than consuming the entire planning phase.
Use the dictionary in examples
Review a few representative records and ask staff to explain each field using the agreed definitions. If a record does not fit, refine the definition or identify an exception. Name someone who can resolve future meaning questions. Your next scoping step is a short glossary of the ten most consequential terms, linked to the workflows they support. Ask the supplier to use those terms consistently in prototypes and demonstrations so language differences are found before they become implementation differences.
Planning checklist
- Define ambiguous terms with examples.
- Explain what each status proves.
- Specify units and the meaning of dates.