Deferred Customer account numbers
It would be nice to be able to add a customer account number when creating a new customer as well as just their name. Xero has an option to assign account numbers to customers which is handy when sending out statements as customers can use their account number as a reference when making payment. Right now I have to add account numbers manually in xero once the customer has been created in DEAR.
Really, really needed - we use a customer field, but it doesn't check for duplictes, so not a good option really, but there's no other way I know of. Please please sort this @Tristan Thomas.
This is a basic lack with the system sadly.
Completely agree with the NEED for customer codes. The GUID is not a customer code and should not be used as such.
This is industry standard and we were very disappointed when we realised that this feature was not available.
I would add that we also need a code for each customer address, this is especially important when trying to update addresses via CSV because there is no unique identifier for each address in the import file. When doing a "create/update" it always create a new address instead updating the existing one.
Absolutely agree with this! We NEED this to service our clients smoothly and efficiently. We simply have too many clients with the same names. PLEASE implement this.
Having the same problem as outlined very well in Robert Thomson's post. Magento 2 in our case. Agree that "a non unique Name field and a unique CustomerID field would solve many issues".
It would save us a lot of headaches and the common occurrence of the data of customers with the same name piling into one customer account.
Steve - the GUID (dear calls it the Customer ID) is covered in a few other posts so it might be worth re-reading this thread from the start.
This identifier is the characters after the # in the Customers URL (in bold below) and can be found by visiting the Customer (Sale > View All Customers then select a customer) and looking at the URL.
ie: https://inventory.dearsystems.com/Customer#e4d26737-fc52-442e-9709-3f06fa3d2194
The way these are generated means you could use the first or last blocks and still be extremely confident you'll never have a duplicate. In the above example e4d26737 or 3f06fa3d2194 are both essentially unique.
The Customer ID is not available through any of the Mail Merge fields but it would be pretty easy to assign the same GUID as an Additional Attribute, or I'm sure it would be fairly easy for DEAR to add the ability to reference the Customer ID through the Mail Merge.
Another option if you're wedded to the idea of having the Customer Name as unique if for you to use that as your customer ID and type your manually created account number when you create the customer. Then use the "Contact" aspect of the customer to add their real name.
1 person likes this
Hi Tim. How do you 'get' the GUID without the API which is not given away for free? (Hence my skeptical world view.)
My guess is that we are all at different stages on our journey of becoming programmers... In the mean time, pragmatically, a visible account number would solve the issue for a lot of us.
You say the customer shouldn't have to remember their account number. I say it isn't necessarily for their benefit, but rather for internal administration of information that DEAR is not built do cater for.
Another argument for you. How much cleaner would it be if there was an option for DEAR and XERO to sync by an account number? Instead we have to diligently ensure the the Company names match in both systems. Or hope the fuzzy AI does a reasonable job.
I guess if we really desperately want to use Account number we can (as someone has previously noted). We'll just have to put up with using an additional attribute buried on the page for now.
HI Steve, your speculation is wrong, which I hope makes you feel a bit better about the world . Of course Dear uses unique identifiers, they are GUIDs and are exposed everywhere in the API. Every integration uses them, not just for customers, but for everything. See the API docs. GUIDs are very cool, they are account numbers on steroids, but they are very big. They solve a lot of problems for programmers, but they are not remotely human friendly.
Robert Thomson's post is a good one. The current situation causes problems in the B2C world. But this problem is quite hard to solve. Account numbers don't help very much. For sure, customer names should not have uniqueness forced upon them, but then what? I don't want my B2C customers to have to remember their Dear account number, it's of no value to them.
1 person likes this
I also completely agree, account numbers are needed. Unique account numbers would obviously allow more robust cross-linking to other data sources. 5 years on and this discussion is still going? Maybe this is why it has never been done. DEAR doesn't want to give away too much.
Completely agree Account numbers are needed. Every system I have ever used has account numbers.
1 person likes this
The fact that Dear uses the Customer Name as a unique identifier is a joke.
Even if you don't want to implement account numbers (noting that this feature request is marked as deferred), at very minimal it should use email address or phone number as the unique identifier in which to avoid duplicates.
In addition to our B2B customers, we have multiple B2C ecommerce shops connected to Dear, all of which are syncing customers to Dear, so the chances of duplicate customer names (e.g. John Smith!) are relatively high!
We've just had the exact situation happen whereby 2 completely separate customers with the same name have been merged into the same Customer by Dear....
Please guys, let's get this sorted.
Well I kept having my post rejected, so I will try to remove the concern the forum gatekeeper was possibly having with it.
Regarding having a separate unique CustomerID field and the shopify concerns here's one way to do it:
Accounts:
CustomerID: 1000,
Name: John Smith, Address: 123 Main St Unit 1, City: Houston, St: TX
Email: js@xyz.com, Phone: 811-555-1212
CustomerID: 5555,
Name: John Smith, Address: 500 Michigan Ave, City: Chicago, St: IL
Email: jonathan.smith@xyz.com, Phone: 313-222-5555
NOTE: Two John Smith accounts are allowed because the CustomerID field has the unique constraint.
Another order comes in from shopify: (using the mangled address example)
Order info:
Name: John Smith, Address: Unit 1, 123 Main St, City: Houston, St: TX
email: js@xyz.com, Phone: 111-111-2222
Check the "strong" indicators of the order first for a match.
"strong" match indicators would be: email, phone, Name/Address (including city, state, and zip)
This order matches on email -> the order is added to CustomerID 1000.
Now if the email wasn't provided, we no longer have an email, phone, or address match.
A new account is created:
CustomerID: 8787,
Name: John Smith, Address: Unit 1, 123 Main St, City: Houston, St: TX
Email: none Phone: 111-111-2222
Now later when our customer service rep searches on John Smith, all three accounts come up (1000, 5555, 8787) and hopefully our customer service rep can verify with the customer, assuming he/she is on the phone, that account 8787 is the same as account 1000 - e.g. maybe the cell phone was provide instead of the main number. Now our customer service person can merge the two accounts. If they are not the same person then there is no harm done, because all the accounts are separated appropriately.
I know this is a simplistic example, but hopefully it illustrates the reason why a non unique Name field and a unique CustomerID field would solve many issues.
This would also allow our customers to refer to their customer id (original request in thread). e.g This is John Smith, can you tell me if I have an account balance? My customer id is: 1000; no confusion, very simple and elegant.
Michael are you aware that I do not work for DEAR? I'm simply a user like you and I'm trying to help you think about your process so that you can try to solve you issues using existing functionality.
You might notice that this topic has been marked "deferred" which means exactly what you state: not a high priority and might be looked at later in the future.
If you are unable to change your workflow and you rely on having a unique account number then I'd suggest one of two things:
1) Use the last X characters of the DEAR-created customer ID as your unique account number. While strictly not unique the chance of these strings being duplicated is tiny.
2) Use the "Customer Name" field in DEAR as your unique account number and add their name or business name as an Additional Attribute.
it would be more professional to lie and say:
"it's up for consideration, but not a high priority. it will be sceduled into the roadmap of improvements for a later date"
@Tristan Thomas, it blows my mind how you are the one replying to these sorts of requests.
you seem unable to simathise with what we have asked for for multiple reasons.
we aren't asking, as you said on Saturday 28th, for 150 different custom fields, this is one field that would help our businesses opperate better.
the unique # that is in the URL would work internally, but not to share with a customer.
the name is obvious, but as mentioed, in many situations, it's not good enough.
I'd still like the feature of selecting between:
This strikes me as an issue with the integration, not DEAR per se. DEAR could have an extra 150 unique fields but you're always going to run into the same issue - what are you going to match a non-unique customer name against?
As you say in point (2) the integration needs to check multiple fields for a best match, but natural language processing / matching is extremely difficult. You and I are good at seeing that "Unit 1 123 Main Street" is the same address as "123 Main St Unit 1" but that's a really difficult for a computer. Matching email address is a better option but many people use different emails as they change employment etc. Matching off a woocommerce / shopify account number would work but only if the customer signs in with the same account and not as a guest.
Ideally the integration would look at a couple of points - maybe name, address, email address and make a decision on best match. If the integration can't confidently match then it should ask for manual help.
But regardless I can't see how an additional DEAR field will solve this?