Free-text notes are often carrying work your system cannot see
A lot of businesses have a system that looks organised on the surface, but the important operational detail is hiding in notes, comments and emails.
A job says "In Progress", but the real situation is buried in a comment saying the site is waiting on customer approval.
A quote looks open, but a note explains that revised pricing was sent last Thursday and someone needs to follow up on Monday.
A task appears complete, but the technician's note says further parts are required.
Humans can read that context. Systems generally cannot act on it reliably.
That is the core problem. Notes are useful for explanation, nuance and exceptions. They are poor at controlling workflow. If critical information only exists as free text, your process becomes dependent on people reading carefully, interpreting correctly and remembering what to do next.
That usually leads to three predictable outcomes:
- actions do not trigger when they should
- reporting becomes unreliable
- downstream work becomes inconsistent
If your team keeps putting operationally important information into notes, the issue is usually not that they are careless. It is often that the system has not given them the right fields to capture what actually matters.
The difference between context and control data
A useful way to think about this is to separate context from control data.
Context is the narrative around the work. It explains what happened, why it happened, what someone observed, or what judgement was applied.
Control data is the information the business needs in order to route work, trigger actions, assign ownership, measure progress or report on performance.
Both matter. They just do different jobs.
Context belongs in notes
Notes are the right place for information such as:
- what the technician found on site
- why an exception was approved
- details of a customer conversation
- extra observations that may be relevant later
- explanation of a non-standard decision
This is human context. It helps the next person understand the situation.
Control data belongs in structured fields
Structured fields are the right place for information such as:
- current status
- next action date
- approval state
- issue type
- responsibility owner
- job outcome
- priority
- required follow-up
- handover readiness
- invoice readiness
This is operational data. It needs to be consistent, visible and usable by the system.
If a value should change what happens next, who owns the task, whether something appears in a report, or whether an automation runs, it probably should not live only in a note.
Why teams fall back to free text
Free text is easy. It asks less of the system design up front.
When a workflow has not been properly thought through, notes become the safety valve. Staff use them because they are trying to preserve reality inside a system that is too vague.
That often happens when:
- statuses are too broad to reflect real operational stages
- forms do not include the fields people actually need
- nobody has defined the source of truth for key information
- responsibilities are implied rather than assigned
- exceptions happen often, but the process was designed only for the ideal path
- the business wants reporting later, but has not decided what data needs to be captured during the work
So the team writes things like:
- "Customer approved verbally, waiting for deposit"
- "Need revisit when weather clears"
- "Installer found damaged fascia, send variation"
- "Payroll to check overtime for Saturday"
- "Call customer next week if no reply"
All of those may be useful notes. None of them are strong workflow control.
The problem is not the wording. The problem is that the system is asking prose to do the job of structured data.
What should usually never live only in notes
There are some types of information that should almost always be captured in a structured way if they matter operationally.
Status
A note saying "waiting on parts" is not a substitute for a proper status.
If the job cannot progress until parts arrive, the system should show that explicitly. Otherwise jobs that are blocked look the same as jobs that are active, and managers cannot tell where work is truly sitting.
Dates and deadlines
If a note says "follow up Friday" or "customer requested install after 14 May", that date needs a field.
Dates drive action. A person may remember to read the note. The system will not reliably act on a sentence.
Approvals
If a variation, quote, leave request or payment requires approval, that state should not be inferred from comments.
Use a field for approval status, ideally with clear values such as pending, approved, declined or not required.
Responsibility
If the next step depends on a specific person or team, ownership must be visible.
"Accounts to review" inside a comment is weak ownership. An assigned owner field or queue is much stronger.
Issue type or reason codes
If jobs get delayed for different reasons, if defects need categorising, or if customer requests vary in meaningful ways, those distinctions should be structured.
Otherwise every analysis later becomes manual interpretation of language.
Outcome fields
Did the site visit result in completion, partial completion, variation required, revisit required, customer not home, safety issue, or something else?
If outcomes affect billing, scheduling, customer communication or operational reporting, record them structurally.
Why free text breaks automation
Automation depends on clarity. It needs known conditions and predictable values.
A workflow can easily act on:
- status changed to "Awaiting Approval"
- follow-up date is today
- issue type equals "Defect"
- approval status changed to "Approved"
- assigned team is "Installations"
It cannot reliably act on 20 different human ways of writing the same thing in a note.
Even if someone tries to build automation around keyword matching, it becomes fragile quickly. People abbreviate, misspell, phrase things differently, or include multiple ideas in one comment. The result is unreliable triggering, false positives and exceptions that still need manual checking.
More importantly, free text does not just make automation harder. It makes workflow dependent on someone continuously monitoring and interpreting notes.
That creates hidden admin work. Someone in the office ends up reading updates, translating them into actions, chasing the next team and manually moving things along. The business calls this coordination, but often it is just compensation for missing structure.
Why reporting gets weak when key information lives in notes
Reporting only works when the data being reported is captured consistently.
If the business wants to know:
- how many jobs are waiting on customer response
- how many quotes are pending approval
- how many revisits were caused by missing materials
- which technician outcomes are leading to variations
- how long work spends in each stage
- how many jobs are ready to invoice but not invoiced
that information needs to exist as fields, not just narrative.
If it only exists in notes, reporting becomes one of two things:
- impossible without manual review
- technically possible but inconsistent and untrustworthy
This is why many businesses feel they have software but still cannot answer basic operational questions without someone going job by job.
The reporting problem is usually not a dashboard problem. It is a data capture problem.
Searchability suffers too
Teams often assume notes are searchable, so the information is still available.
Technically, maybe. Operationally, not really.
Searching free text only works when:
- people know exactly what wording was used
- everyone describes the same thing the same way
- the information was recorded in the same place every time
- nobody needs a precise count or filtered view
In practice, one person writes "awaiting client", another writes "waiting on approval", another writes "no response from customer", and another logs nothing except an email thread elsewhere.
That is not searchable in a useful operational sense. It is just recoverable if someone has time to investigate.
Structured data makes information findable by design. You can filter it, count it, assign it, trigger from it and review it consistently.
Better field design does not mean turning everything into a rigid form
One common mistake is swinging too far the other way.
Once a business recognises the problem with notes, it can overcorrect and create bloated forms with too many mandatory fields, too many status values and too much complexity for frontline staff.
That is not better systems design. It just creates a different kind of friction.
The goal is not to structure everything. The goal is to structure the information that the business needs to operate reliably.
A well-designed process usually has:
- a small set of clearly defined status values
- key dates captured in dedicated fields
- visible ownership
- standard outcome or issue categories where they matter
- notes for explanation, nuance and edge cases
The test is simple: does the field support action, visibility, reporting or handover? If yes, structure it. If it is explanatory detail around that decision, note it.
A practical way to decide what should be a field
If you are unsure whether something belongs in a note or a structured field, work through these questions.
1. Does this information change what should happen next?
If yes, it likely needs structure.
For example, "requires customer approval" should not just be a comment. It changes the workflow.
2. Does someone need to filter, count or report on it later?
If yes, use a field.
If you want to know how many jobs are delayed by materials, you cannot rely on narrative wording alone.
3. Does this information determine ownership?
If the answer affects which team or person is responsible, capture it structurally.
4. Is there a date attached to it?
If a sentence implies a due date, follow-up date, target date or hold-until date, use a date field.
5. Would an automation ever need to act on it?
If an email, notification, task creation or status progression depends on it, it needs predictable structure.
6. Is it one of a recurring set of scenarios?
If the same type of issue keeps appearing, a category field may be appropriate.
7. Is it explanation rather than instruction?
If it is there to explain why something happened, preserve it in notes.
In most workflows, the answer is not either/or. You often need both.
For example:
- Structured field: Status = Awaiting Customer Approval
- Structured field: Follow-up Date = 16 May
- Structured field: Owner = Sales Coordinator
- Note: Customer requested a revised layout because the access path changed after site inspection
That combination is much stronger than putting everything into a single comment.
A simple example of context versus structure
Take a field technician finishing a site visit and discovering extra work is needed.
A poor data design might produce one note:
"Completed main install but downpipe issue found at rear of property. Customer shown on site and verbally approved additional works. Need office to send variation and book return next week when parts arrive."
There is useful context there, but too much of the workflow depends on someone reading and interpreting it.
A better design might capture:
- Job outcome: Partially complete
- Issue type: Variation required
- Customer approval status: Verbally approved
- Parts required: Yes
- Return visit required: Yes
- Responsible team: Office scheduling
- Next action date: 13 May
Then the note can preserve the human detail:
"Downpipe issue found at rear of property. Customer advised on site. Access is tight, so return visit should allow extra time and bring offset fittings."
Now the system can move work properly, and the note still carries the operational nuance.
Preserve human judgement without losing structure
Some businesses resist structured data because they fear oversimplifying real work.
That concern is valid if the system is badly designed. Not every situation fits neatly into a dropdown. Not every exception can be predefined.
But the answer is not to abandon structure. It is to separate the parts of the process that need consistency from the parts that need judgement.
Human judgement is still essential for:
- interpreting unusual situations
- deciding whether an exception should be approved
- explaining risks or constraints
- recording customer-specific context
- documenting observations from the field
What structured data does is reduce ambiguity around the operational basics:
- where the job sits
- what state it is in
- who owns the next step
- what action is pending
- whether approval exists
- what date matters next
You are not trying to replace judgement. You are trying to stop judgement from being the only thing holding the workflow together.
Signs your business has a notes-versus-structure problem
You likely have this issue if any of the following are common:
- staff say, "It's in the notes"
- managers need to open records one by one to understand status
- reports require manual interpretation
- tasks get missed because no formal trigger exists
- handovers depend on someone giving verbal context
- ownership becomes unclear after a status change
- teams use comments to assign work instead of actual assignment rules
- follow-ups happen because someone remembered, not because the system prompted them
- similar situations are described in many different ways
These are not just documentation issues. They are workflow design issues.
How to improve it without rebuilding everything
You do not need a major platform replacement to fix this. In many cases, the better move is to redesign a few important fields and handover rules inside the systems you already use.
A practical approach looks like this:
- Review a sample of real notes, comments and emails.
- Highlight the information people repeatedly record.
- Identify which parts affect status, ownership, timing, approvals or reporting.
- Turn those recurring operational elements into structured fields.
- Keep notes for explanation and edge cases.
- Update forms and handover steps so staff can capture the new fields easily.
- Make sure each field has a clear owner and purpose.
The key is not adding fields for the sake of completeness. It is capturing the minimum structured data needed to make the workflow reliable.
What good looks like
A well-designed workflow does not force people to choose between structure and context. It uses both properly.
Good operational design usually means:
- the current state of work is visible without reading long notes
- the next action is clear
- ownership is obvious
- key dates are trackable
- approvals are explicit
- recurring issue types can be reported on
- notes add detail instead of carrying the whole process
- automation works because it is triggered by fields, not interpretation
- managers can see what is happening without reconstructing it manually
That is when the system starts doing its job properly. Staff still communicate, explain and document. But they are no longer using prose to compensate for missing workflow design.
The real goal is reliability
If important operational information only exists inside free-text notes, your business is relying on careful reading, memory and individual interpretation to keep work moving.
That may function for a while, especially with experienced staff. It usually breaks as volume grows, teams change, or more handovers and exceptions appear.
The fix is not banning notes. It is being deliberate about what notes are for.
Use notes for human context.
Use structured fields for anything that needs to trigger action, assign responsibility, support reporting or create visibility.
If your current workflow spans multiple teams and systems, mapping what information should be context versus control data is often where reliability starts. That kind of process design work is exactly where 5M Consulting can help.