Keep a Business Account Separate from Its Contact People

1. Start with three different questions

Before creating fields or choosing software, separate three everyday questions. “Which organisation are we dealing with?” is answered by the business account. “Which individual spoke or wrote to us?” is answered by the contact person. “What does that individual handle for this organisation?” is answered by the relationship between them. Treating all three as one customer entry makes routine changes look like identity changes.

Suggested practice: use a business account for the organisation’s working identity and shared business context, such as its displayed trading name, general location context, and notes that genuinely apply to the organisation. Use a contact record for the individual’s name and individually attributed contact methods. Use a relationship note for role context, such as purchasing contact, receiving coordinator, or quotation recipient. This is a working model for clear records, not a claim about a particular product’s data structure.

A company switchboard, a shared inbox, or a familiar name can help staff find a record, but none proves a person’s identity or role. Mark unverified details as needing confirmation rather than silently converting a clue into a fact. The distinction is especially useful when different colleagues use one main number or when an employee leaves but the business remains an active account.

2. Give each record a stable reference

A name is useful for recognition, but it is not enough to preserve meaning when names are similar, corrected, or incomplete. Suggested practice: give the business account its own stable reference and give each contact person a separate stable reference. Keep each reference attached to its record when a displayed name, phone number, email address, or role changes.

Do not use a phone number as the primary identity of either record. A reception line can belong to many colleagues, and an individual may change numbers. Do not use a row number either: it identifies a current position in one list, not the account or person after sorting. A reference need not be elaborate; its value is that staff can locate the same record again without guessing.

When staff make a note, identify the relevant account and contact where both matter. For example, a note can refer to the account reference and the person reference, then state the communication context. This keeps a later reader from assuming that a message from one colleague speaks for every person at the account. For wider reference conventions, see the guide on stable record references before moving data.

3. Put role context on the relationship

A role is not simply a label attached forever to a person. It is a statement about a person’s connection to a particular account at a particular time. The same individual might be a purchasing contact for one account and a receiving coordinator for another. Conversely, one account may have several people with different responsibilities at the same time.

Suggested practice: for each confirmed relationship, record the account reference, contact reference, role description, whether the relationship is current or historical, the date or period if known, and a short verification context. Verification context can say who confirmed the role or which ordinary business communication supplied it. If the date is uncertain, say so rather than inventing a start or end date.

Keep the role description operationally useful. “Handles purchase orders” or “confirms delivery access” is clearer than a broad label that does not tell staff what may be discussed with that person. Avoid turning a role note into an authority claim. A person who receives delivery updates is not necessarily the person who approves quotations or payments. When the real scope is unknown, record it as unknown and assign a narrow confirmation step.

4. Let several contacts share one account without repeating company facts

An account can have a purchasing contact, a site contact, and a finance contact. Repeating the organisation’s name, address context, or general notes in three separate person entries creates three versions that can drift apart. Keep the organisation-level information once on the business account, then connect each person through their own relationship record.

Suggested practice: review an account from both directions. From the account, staff should be able to see the current people and their practical roles. From a contact person, staff should be able to see the relevant account relationship without assuming the person belongs only to that account. If a person’s relationship is not verified, keep it distinct from confirmed relationships.

This approach also makes handoffs less fragile. A new team member does not need to interpret a single overloaded “contact” box. They can see whether an incoming question belongs with purchasing, site coordination, or another relationship. Do not delete a useful earlier person merely to make the account view shorter; historical communication may still need its original person and account context.

5. Change a contact without rewriting history

When a business confirms that a new colleague now handles purchasing, the business account has not become a new business. Nor has the earlier colleague automatically become a duplicate. Suggested practice: create or confirm the new person record, record the new current relationship, and mark the earlier purchasing relationship as no longer current when that is verified. Keep earlier messages linked to the person who actually sent or received them.

Open work needs a deliberate handoff. List each live quotation question, callback, delivery query, or other next action connected to the departing relationship. For each item, state the current owner, the immediate next action, and whether the new contact has been confirmed as the appropriate recipient. Do not move a promise solely because a replacement person exists.

If two person records might describe one individual, that is a separate identity question. Use evidence to review the pair rather than merging records because they share an account, email pattern, or phone channel. The duplicate-customer review guide can support that separate decision. The purpose here is to preserve a real account-to-person relationship, not to decide that two people are one identity.

6. Fictional example / 虚构示例: an office-supply account

Fictional example: Northline Stationery is an invented business account with account reference BA-041. Its general office line is recorded as a shared channel, not as a person’s identity. Contact CP-116, Farah, has a confirmed current relationship recorded as “purchasing contact.” Contact CP-117, Daniel, has a confirmed current relationship recorded as “receiving coordinator.” The account remains one organisation, while the two people have different work contexts.

A later message confirms that Mei, contact CP-143, now handles purchasing. Suggested practice: record Mei’s current purchasing relationship to BA-041 and mark Farah’s purchasing relationship as historical with the confirmation context. A previous quotation question from Farah remains attached to Farah and BA-041 because that is the actual communication history. A still-open quotation follow-up is reviewed separately: the team confirms whether Mei should receive it, records the next action, and keeps an accountable owner.

Nothing in this example automatically merges contacts, rewrites messages, or proves authority. The account’s identity does not change merely because the current purchasing contact changes. These invented teaching records are not customer data or customer results.

7. Use a worksheet before implementation

Suggested practice: test the model with a small worksheet before asking for a system build. Create one account row, one row for each contact person, and one relationship row for each account-person connection. Include stable references, readable names, role context, current or historical status, verification context, and any open-action reference. Use only ordinary, real workflow information your team is permitted to handle.

The supplied Customer Follow-Up CRM service page says a first version may track customer stage, last contact, next follow-up date, and the person in charge. That is product-page context about follow-up scope, not a statement that BossFlow or any current system provides a particular account-contact model. The account, person, and relationship worksheet in this guide is original suggested SME practice.

Once the meanings are clear, implementation choices, access rules, data movement, and quotation discussion need a separate BossFlow workflow review. SME Systems provides education; BossFlow handles workflow review and implementation discussion. Source note: Custom Customer Follow-Up CRM Service Malaysia | SME Systems — stated first-version follow-up context only.

Practical Checklist

• Create a separate business-account reference and contact-person reference before editing live records.
• Keep a shared phone number or inbox as a contact channel, not identity proof.
• Write one relationship entry for each confirmed account-person connection.
• Record a practical role and verification context; mark unknown details as unknown.
• Keep company-level facts on the account instead of copying them into every contact record.
• When a role changes, update the relationship status instead of overwriting earlier communication history.
• List open actions, owners, and next steps before handing work to a new contact.
• Review possible duplicate people as a separate evidence decision.
• Desk-check the worksheet with one account and at least two contacts before implementation.