Matching a company by its email domain
Most service desks care about the account, not the individual. Three people at the same customer raise three requests and an agent wants the same context on all three: the plan they are on, the renewal date, the account manager. Matching the person cannot give you that unless every one of those people is in your CRM as their own record.
Matching their company solves it from the other end. The address is reduced to its domain, the domain finds one company record, and every reporter at that customer shares the answer. It also brings a risk that matching a person does not have, because a domain can belong to more than one thing, and this page is mostly about what the app does with that.
#What is taken from the address
The domain is everything after the last @, lower-cased, with a trailing dot removed. The part before the @ plays no part at all and is dropped before the lookup runs.
Some addresses have no usable domain in them. An entry with no @ in it, no dot after it, a space inside it, or a bracketed IP address in place of a host is treated as having no domain, and nothing is looked up.
#Subdomains, and how far up the app looks
Real addresses are often on a subdomain while the CRM holds the plain company domain. So a lookup does not offer one domain, it offers the domain and its shorter forms, up to four parts deep, and lets Attio discard the ones that match nothing. A reporter at mail.acme.co.uk therefore still finds a company stored as acme.co.uk.
#A Domain attribute and a Text attribute are not compared the same way
Which of the two you picked on the Matching step changes what will be found, and the screen says so under the picker.
Attribute type | What the domain is compared against | What that means |
|---|---|---|
Domain | The registrable domain Attio works out for itself | "Attio compares the registrable domain, so a reporter at mail.acme.co.uk still finds a company stored as acme.co.uk." |
Text | The whole stored value, exactly | "A text attribute is compared whole, so this only matches a record whose text is exactly the reporter's domain. A reporter at mail.acme.co.uk will not find a record holding acme.co.uk. A Domain attribute is the more forgiving choice." |
#How many records a domain is allowed to match
This is the rule that keeps the wrong customer off a card, and the Matching step states it in full under the heading "How many records a domain is allowed to match": "One record and the card shows it. Up to 3 and the agent is asked which one. 4 or more and the card shows nothing at all, because a domain that resolves to that many records is almost always free mail, a shared host or an email-service sending domain, and every candidate on the list would probably be the wrong customer."
Records holding the domain | What the agent sees |
|---|---|
One | That record, with its chosen attributes and a link out to Attio |
Two or three | A short list of candidates to open in Attio, and no values |
Four or more | Nothing at all. The card reads as a plain no-match |
Cutting off at four costs nothing extra. The lookup already asks Attio for one more record than the card will ever list, which is how the app knows there are more without asking a second time.
The free-mail list is not what keeps the wrong customer off the card. No list of free-mail domains can be complete, and the problem is not confined to free mail anyway: an ordinary business domain can fan out to several company records in a CRM that has been enriched, and a sending domain belonging to an email service can end up as a company record of its own. The protection that actually holds is the four-or-more rule above. Treat the ignored-domain list as a courtesy that saves a pointless lookup, not as the safety net.
#One answer for the whole company
Because the lookup is keyed on the domain rather than the person, one answer serves everybody at that customer. Two agents looking at two requests from two people at the same company share the same result, and a second view costs no call to Attio at all. An answer is kept for fifteen minutes, so an edit made in Attio can take that long to reach a card.
Changes you make in project settings do not wait for that window. Changing the record type, the match method, the attribute matched on, the fields on the card or either domain list takes effect on the next view.
#Trying an address before you switch the card on
The Fields screen takes a test email address and fills every attribute row with that record's real values, so you can tell a useful attribute from an empty one before agents ever see it. In company mode the note above it reads "Only the part after the @ is looked up, so any address at a customer's domain gives the same answer. This is your own test address, not a reporter's." and then names the domain it is matching on.
If the address you type is one that would never be looked up, the screen says which of the three reasons it was and spends no lookup: the address has no domain in it, the domain is on the list this project ignores, or the domain is one of the two families that can never identify a company. Any values still on screen underneath are from the last address that was looked up, and the panel says so.
#A few things worth knowing
A Text attribute does not do the subdomain work a Domain attribute does. If your workspace keeps domains in a plain text field, a reporter at mail.acme.co.uk will not find the record holding acme.co.uk, and the failure looks exactly like the company not being in the CRM.
Four or more matching records reads as a plain no-match on the card. There is no sentence telling an agent that a domain was too crowded to call, so the one case you most want to know about is the one that looks most ordinary.
The hint on the Fields screen names the whole host it read out of your test address, for example "Matching on mail.acme.co.uk.", while the lookup also tries the shorter forms of it. A match found on acme.co.uk is still reported under the longer name.
#Related
A domain is a strong hint and a weak promise.
