Picking the Survivor

When a contact case asks "which customer number should they keep?", this is how to choose. The number you pick becomes the customer's number everywhere; the checker corrects the HubSpot contacts to it and merges them (history kept). MOM is never changed by the checker; the losing MOM record is for whoever maintains MOM to retire.

The rules here are a starting policy, not a fixed one. This page is yours to develop and adapt as you answer cases, and it is meant to grow in two directions:

• Confusion in, tree out. When a case leaves you unsure which number should win, that is a question the tree does not answer yet. Say so with Suggest a rule on the case; the answer becomes a new box or a new branch here, so the next person is not stuck at the same place.
• Patterns out, policy up. When you notice you keep answering a kind of case the same way, that is a policy. Suggest it the same way. Once a rule is written down and the answers really are always the same, it can stop being a question at all: the checker applies it automatically and the case never reaches you. Every automatic rule the checker has today started as a question somebody answered by hand.

So: a suggestion may change this tree, or it may retire a whole scenario from the queue. Both are wanted.

The one question before any of this

Are these records the same customer at all? If not, the answer is Different people, or Different customers, same organisation when they work at the same place. No survivor is picked. When in doubt, Different is the safe answer: it is easy to undo, a wrong merge is not.

The general flow

flowchart TD
  A(["Same customer?"]) -->|no| D1["Different people, or<br/>Different customers, same organisation"]
  A -->|yes| B{"Does one record only ever<br/>receive shipments?"}
  B -->|yes| S1["Keep the BUYER's number.<br/>The other was an address, not a customer"]
  B -->|no| C{"Is one number unknown to MOM?"}
  C -->|yes| S2["Keep the number MOM knows.<br/>A number MOM never issued cannot survive"]
  C -->|no| E{"Does one number have invoices<br/>in QuickBooks or deals in HubSpot?"}
  E -->|only one| S3["Keep that number.<br/>Accounting history is keyed to it"]
  E -->|both or neither| F{"Which number was used<br/>to buy most recently?"}
  F -->|one is clearly newer| S4["Keep the number the customer<br/>is actually using"]
  F -->|same order, or no orders| S5["Keep the OLDER number.<br/>It has been referenced longer"]

Read it top to bottom and stop at the first box that decides. The boxes are in order of how strong the reason is: a shipment-only record is never a customer; a made-up number can never win; accounting history should not move; recent use beats age.

What to look for on the case, and why

• Has orders / has deals on each record. A record that never bought anything is either an address row from MOM or a lead; it should not be the survivor.
• Last order date. The address the customer used last is the one they will use next. Receipts and marketing should go there.
• Customer number in MOM? The case says when a number does not exist in MOM at all (S8). That number was typed by hand and is wrong; it never survives.
• The shipping address. A MOM record whose only role was "ship here" shows a shipping address and no billing history. That is the address row, not the person.
• Company. Two people at one agency are two customers. If the records are colleagues, the answer is Different customers, same organisation, and each keeps their own number.
• Typos. A hint on the case marks a likely typo in a name, email or number. A typo is one person; pick by the rules above, then note the correct spelling so MOM can be fixed.

Per scenario

S1, entered twice in MOM. Straight down the flow: buyer over ship-to, then QuickBooks history, then most recent order, then the older number.

S2, the HubSpot contact carries a different number than the match. Usually the matched MOM customer's number wins, because that is who the email and name say the contact is. Exception: if the number already on the contact has invoices in QuickBooks, keep it and treat the MOM match as the duplicate to retire.

S3, two HubSpot contacts with two numbers. Same as S1, decided by the numbers, not by the contacts. Whichever contact carries the chosen number stays; the other is merged into it and its email becomes an additional email. You do not pick the contact, only the number.

S4, a buyer and someone they ship to share a name. The buyer's number. The other record is an address, or a family member who never bought. If that person later buys under their own email, they get their own number then.

S5, one email, several different people. Not a survivor question: they are different people. HubSpot can hold the email on only one contact; it stays with the person who bought most recently. The others get a contact without that email until they use their own.

S6, one email, one person entered twice. Same as S1. Pick the number; the email stays on the one HubSpot contact.

S7, linked records but the last names differ. First decide whether it is one person (a marriage, a hyphenation, a typo, "Van Dyke" and "VanDyke") or two. One person: pick by the flow. Two people: Different.

S8, a number MOM does not know. The MOM number, always. If nothing in the case matches a MOM customer, choose Different so the contact keeps its number for now; it stays flagged as a bad number.

S10, the number this contact should carry is already on another contact. If the two HubSpot contacts are the same person, pick the number: they merge into the contact that already carries it. If not, Different: the matched contact is left without a number and flagged for a person.

How a suggestion becomes a rule

1. You press Suggest a rule on a case and say what you would always do here and why. It is filed as feedback with the case attached.
2. It is written up as a change to this page, or as a new automatic rule, and shown back to you with the cases it would have decided.
3. If it holds, the page changes, or the checker starts applying it and that kind of case stops appearing. The rule is dated here so you can see when the policy moved.

Two rules from the first review are already on that path: last names that differ only by a space or a hyphen count as the same name, and a MOM record that is the same person at a second address takes the buyer's number without asking.

After you save

• Off (the default setting): the change reaches HubSpot on the next contact push, or when Revise runs on that contact.
• With Apply decisions immediately on: the merge and the number correction happen at save time, on the test portal.
• Either way the losing MOM record is still in MOM. Tell whoever maintains MOM which number lost, so it can be retired or pointed at the winner.