Unknown, Not Applicable or Confirmed?

1. Notice what is hidden inside an empty-looking field

An SME record may show a blank equipment requirement, a dash in a preferred contact window, or 0 beside a quantity. Those marks are often used interchangeably even though they answer different questions. The customer may not have been asked. The requirement may not apply to the job. A staff member may have received an answer but not checked it. Or zero may be the confirmed answer. When all of these become an empty cell or a casual placeholder, a filter cannot show what needs follow-up and an owner cannot tell whether a record is safe to proceed.

Suggested practice: first choose one field that changes operational work, such as access equipment required, preferred contact window, tax reference supplied, or site contact available. Review ten recent records without changing them. For every blank, dash, zero, and unchecked note, write its actual meaning beside it. The repeated meanings—not the wording people happened to type—are the states your team must distinguish. Avoid starting with every field in the system; one confusing field is enough to test a better rule.

A blank should have one restricted meaning: no value has been entered. It should not quietly mean no, none, unknown, irrelevant, or waiting. If your current spreadsheet cannot enforce that meaning, put the state in a separate column or structured note until the workflow is redesigned. This makes a blank visible as unfinished information rather than an apparent answer.

2. Separate the business value from the verification state

The value answers the business question. The verification state answers how much the team can rely on that value. For an optional access-equipment requirement, the value might be “equipment required,” “no equipment required,” or no stated requirement. Its state might be unknown, pending verification, confirmed, or not applicable. Keeping these ideas apart prevents “no equipment required” from being mistaken for “nobody has asked.”

Suggested practice: use a simple two-part pattern for fields that matter. First record the value where known; then record a state. Unknown means the team does not yet know the answer. Pending verification means an answer or indication exists, but the named check has not happened. Confirmed means a person has checked the value against the evidence your workflow accepts. Not applicable means the question genuinely does not apply to this record type or circumstance.

Do not create a state merely to make a report look complete. A confirmed state should be possible only when staff can say who confirmed it, when, and from what normal business evidence. A state alone is not proof, and it should not replace source documents or normal operating records. The aim is clear next actions, not a claim of certainty beyond what the team can support.

3. Build a small field-value dictionary

A field-value dictionary is a short shared instruction for one field. It is more useful than a long data policy because it tells a staff member exactly what can be entered, what each choice means, and what happens next. Start with fields that affect a booking, quotation, assignment, follow-up, or exception. Leave ordinary descriptive fields alone until the team can use the first dictionary consistently.

Suggested practice: give each dictionary entry six parts: field name; business question; allowed values; allowed verification states; observable examples; and the person who may confirm the value. Add a final instruction for the next action when the state is unknown or pending verification. For example, the “preferred contact window” field may permit a stated time range as a value, while “pending verification” directs the assigned owner to ask the customer before a time-sensitive call.

Write examples around real observations, not guesses about intent. “Customer replied by message that afternoons are easier; confirmation still required” is a usable pending-verification example. “Probably afternoons” is not. Explain whether a dash is prohibited, whether zero is valid, and whether staff should leave the value blank while selecting unknown. A small dictionary reduces improvised alternatives such as N/A, nil, -, 0, and “check later.”

4. Make verification visible and accountable

A record becomes dependable when a person can locate the basis for a meaningful value. For each confirmed value, record the verifier, verification date, and a short evidence reference such as a call note, approved form, or source message reference used in the normal workflow. Do not copy unnecessary personal or sensitive content into the field merely to prove that a check occurred.

Suggested practice: assign pending verification to one current owner with one immediate next action. “Confirm access requirement before scheduling” is clearer than “follow up.” If timing matters, add a review date. When the owner completes the check, update both the value and state together, then record the evidence reference. If evidence conflicts, do not select the most convenient answer; return the record to pending verification and state what must be resolved.

A person who enters information is not automatically the person authorised to confirm it. Your dictionary should name the appropriate role for each sensitive or operationally important field. This protects staff from being asked to certify something outside their work and gives the owner a clear escalation path.

5. Use not applicable carefully

Not applicable is useful only when the business question cannot reasonably apply. It is not a shortcut for “we do not know,” “we have not asked,” or “there is nothing recorded.” For example, an optional access-equipment question may be not applicable where a record is an early general enquiry with no identified site and no scheduling decision. Once a site-specific service is being arranged, the same question may become relevant and should move to unknown or pending verification rather than remain not applicable.

Suggested practice: define the triggering condition that makes a field relevant. Put it in the dictionary: “Required once a site visit is proposed,” or “Required only for delivery jobs.” Review not-applicable values when a record changes stage, job type, or scope. This avoids carrying an old exemption forward after the record has become actionable.

Do not use zero as a substitute for not applicable. Zero answers a numerical question: the measured or confirmed amount is zero. Not applicable says there is no applicable numerical question for this record. This distinction matters when an owner filters for work that needs information rather than work whose answer happened to be zero.

6. Fictional example / 虚构示例: test the rules before rollout

Fictional example: a fictional service enquiry has an optional access-equipment field. The customer has not yet been asked about site access. The value remains blank and the state is “unknown”; the assigned owner’s next action is to ask before scheduling. A different fictional record states that no equipment is required after the customer confirms the access arrangement. Its value is “no equipment required,” its state is “confirmed,” and the record identifies the verifier and source reference. A third fictional early enquiry has no site or scheduled service yet. The state is “not applicable,” with the dictionary trigger showing that the question must be revisited if a site visit is proposed.

Fictional example: a customer message says mornings are usually convenient, but the team needs a definite contact window for a planned call. Record the stated window as “mornings” only if that wording is useful in your workflow, and set its state to “pending verification.” The owner asks for confirmation before relying on it. Do not convert a casual indication into a confirmed preference just because the record requires a value. These are invented teaching cases, not customer results.

Suggested practice: run the dictionary on five to ten completed or live records with the people who enter and use the data. Ask whether two staff members choose the same state from the same evidence. If they do not, improve the example or definition before changing forms, imports, or reports.

7. Keep product facts separate from your own workflow rules

HubSpot’s documentation describes properties as fields that store information on records, including custom properties. Its validation-rules documentation says validation can be set for certain text, date, and number properties, with stated enforcement scope and exceptions. These are HubSpot-specific product statements, not promises about another system, a plan, an integration, or your account.

The field-value dictionary, evidence standard, review trigger, and owner rule in this guide are original suggested SME practice. Use them only after adapting them to the records and responsibilities your team actually has. When the rules are agreed and you need implementation choices, permissions, or a quotation discussion, take the real workflow to BossFlow rather than treating this guide as a software specification.

Source note: HubSpot Knowledge Base, “Create and edit properties”: HubSpot Knowledge Base: Create and edit properties. HubSpot Knowledge Base, “Set validation rules for properties”: HubSpot Knowledge Base: Set validation rules for properties.

Practical Checklist

• Choose one field whose unclear value affects real work.
• List the actual meanings currently hidden in blanks, dashes, zeros, and notes.
• Define allowed business values separately from unknown, pending verification, confirmed, and not applicable states.
• Write an observable example and a prohibited shortcut for each state.
• Name the role allowed to confirm the field and the evidence reference to record.
• Give every unknown or pending item one owner and one next action.
• Define when not applicable must be reconsidered after a stage or scope change.
• Test the dictionary on recent records before changing a form or report.