A CRM Field Dictionary Your Sales Team Can Actually Use
Two salespeople select “qualified” for different reasons. One means the company fits the target market. The other means a buyer has described a project. The records look consistent until the team tries to decide which deals deserve work this week.
A field dictionary gives each important field a shared meaning. Start with the decisions your team needs to make, then define the information that supports them. This is useful before configuring a CRM, adding fields to an existing system or asking colleagues to complete more records.
Give every field a job
Ask what someone will do differently after reading the value. “Next action” helps an owner act. “Action date” tells them when. A field called “relationship temperature” may add little if nobody can explain what changes when it moves from warm to hot.
Keep three kinds of information separate: something the buyer said, an interpretation by your team and an action you have decided to take. A field called “budget confirmed” should not mean “the company seems large enough.” The label must match the information being recorded.
Choose a small working set first. You can expand it after a real task reveals a gap.
Write the rule beside the label
The following dictionary is an original working example for a fictional two-person consultancy. It is a design worksheet, not a description of fields available in Konekt.
| Field | Meaning | Acceptable example | Who updates it? |
|---|---|---|---|
| Client task | Work the client has described | Reduce manual preparation of the weekly plan | Deal owner after the conversation |
| Decision still needed | The specific choice preventing progress | Operations manager to choose workshop or written review | Deal owner |
| Next action | One concrete piece of work | Send the two workshop dates requested | Person doing the work |
| Action date | Date that work is due | Agreed sending date, with timezone if relevant | Action owner |
| Decision source | Where the information came from | Link to the client's reply | Person recording the fact |
| Amount under discussion | Value of the current proposal | Amount linked to the current proposal version | Deal owner |
Add a short rule for an unknown value. “Not discussed” can be useful when the conversation has happened but the subject has not. “To check” needs an owner and a reason to check. An empty value should not silently mean both.
Make fields required when the work requires them
A new enquiry may need a contact, a described task and an owner. It may not have an amount yet. Requiring an amount at creation can encourage guesses that later appear in reports as facts.
Use a simple worksheet for each proposed requirement: at what point is this information needed, who can know it, what happens if it is absent, and where does the user record the exception? Even if your CRM cannot make requirements vary by stage, the team can use these rules during its review.
For the fictional consultancy, a proposal reference becomes necessary when someone sends a proposal. A signature date remains unknown while the client is deciding. The team records a target date separately if it has a reason to discuss one.
Test the dictionary with two people
Give two colleagues the same fictional conversation and ask each to complete a record independently. Compare the results. If one person writes a decision in “next action” while the other writes an internal reminder, improve the definition before correcting either colleague.
Then ask a third person to use the completed record: what should happen next, who owns it and what is still uncertain? A field earns its place when it helps them answer. Rename confusing fields, combine duplicates and remove information that nobody uses.
Keep the dictionary dated, with one person responsible for approving changes. When a meaning changes, decide how older records will be interpreted. Changing the label alone does not correct their contents.
Bring the dictionary to your CRM evaluation
If you are considering Konekt CRM, take this short dictionary and one fictional deal to the evaluation. Check how you can represent the information, find it again and explain an unknown value. Confirm any configuration and plan requirements before relying on them.
The useful result is a record another colleague can act on without asking its author to translate it.