When a Notes field is really a missing table

Every CRM has a Notes field, and in most businesses it is holding information that belongs somewhere else. The tell is an unwritten convention. Everybody types the date first, or puts the trade account number on the last line, and new starters learn it by reading old records. That convention is a schema in disguise.

The field itself is not the problem. Notes exists for the conversation, the context and the reason somebody decided something, and it does that job well. The problem starts when structured facts move in, because a text box cannot answer a question about them.

What the arrangement costs

A text box resists filtering, totalling, sorting and charting. A question about it becomes somebody reading records one at a time. With two hundred contacts that is an afternoon. With two thousand it is a question the business stops asking, which is worse, because the answer was the point.

The format also drifts. Six months of entries by four people produce four conventions, and the oldest entries no longer match the newest. Anybody trying to extract the information later has to handle every variant. That is the work a proper field would have prevented at no cost.

Three signs it wants fields

• A repeating shape. Every entry has the same parts in the same order.
• A question nobody can answer. How many customers sit on that account type, and nobody knows.
• A spreadsheet beside it. Somebody keeps the real version in a file of their own.

Any one of those means the information wants structure. All three together mean somebody is already doing the work by hand, every month, and has stopped mentioning it.

A field for a fact, a table for a list

The distinction is simple and it decides the design. One fact per contact is a field: an account number, a rate, a preferred delivery day. Many rows per contact is a table: every visit, every piece of equipment, every conversation. Diract CRM supports both, so the choice is about the information rather than about effort.

Relationships deserve the same care. A field holding a customer's name as text cannot answer what that customer owns, and somebody will eventually spell it differently. Our guide to choosing a field type covers using a relation instead, so the link survives a rename.

Start from the question, and move one fact

A table designed by listing everything somebody can imagine produces thirty columns, most of them permanently empty. Starting from the questions the business asks produces a much shorter list. Every field in it then has a reason, and the reason is the thing that gets it completed.

Scope matters as much as design. Pulling the single most asked about fact out of Notes into a Diract CRM field takes an afternoon. It also answers the question that prompted the work. A full redesign of the record takes a fortnight and usually stalls. Diract CRM adds a field to an existing record without disturbing what the note already holds, which is what makes the incremental version possible.

Who does the moving, and how you know it worked

The person who has been typing into Notes for two years knows the convention better than anybody. They also know the parts that changed, and which entries never followed it. Designing the fields with them takes an hour and produces a shorter, more accurate list than any amount of guessing from the outside.

The proof is not the migration. It is answering the question that prompted it, in one filter, in front of the person who asked. A business that still cannot answer it has fields in the wrong shape rather than a data problem. That is worth finding out on the first afternoon rather than the second fortnight.

Keep the old text, retire the spreadsheet

Moving to fields does not mean deleting what Notes held. The old text is the history, and some of it will never map cleanly onto anything. Copying across what parses, and leaving the rest readable, is the version nobody regrets. Conversation and context stay in the note permanently, because that is their proper home.

The parallel spreadsheet is the part that has to end. A file somebody maintains separately becomes the version they keep updating, and then two records disagree. Our guide to replacing spreadsheets covers naming a date, telling everybody, and making the file read only.

What to change first

• A repeating shape inside Notes becomes real fields
• One fact per record is a field, many rows is a table
• The design starts from the questions, not a column list
• Relationships use links rather than typed names
• One fact moves first, rather than a full redesign
• Conversation and context remain in the note
• Any parallel spreadsheet retires on a named date