I had two people on my team with similar names.
Not identical. Similar enough that when I built an automation that referenced team members by display name, the fuzzy matching got confused. Tasks intended for one person were showing up in the other’s queue. Notifications were going to the wrong inbox. For about two weeks, I thought one person was ignoring their queue. They were not. The queue was invisible to them.
I found out during a 1:1 when they mentioned offhand that things seemed slow. Their queue had twelve items in it, none of which they had seen.
The automation had been confidently misdirecting work for two weeks. It never errored. It just quietly got it wrong.
What I Had Built
The routing logic pulled a name from a source system and matched it to a display name in the destination system. Simple string match with some tolerance for minor differences.
The problem: the source system used one name format, the destination used another, and two team members were close enough that the tolerance margin swallowed the distinction between them.
The automation matched confidently. Wrong, but confident. That is the worst kind of wrong because you do not get an error. You get silent failure.
Why This Is Entirely My Fault
I am not being falsely humble here. This was a straightforward architectural mistake.
Names are not identifiers. They are labels. Labels change, collide, and get formatted inconsistently across systems. A person can have the same display name as a colleague, go by a nickname in one system and a full name in another, or change their name entirely and break every name-based reference you have ever built.
Identifiers do not do this. A user ID, an email address, an internal system key: these are stable, unique, and system-generated. They do not depend on how someone spells their name in Slack versus how the HR system recorded it at onboarding.
I knew this. I have known this for years. I built the automation in a hurry, used names because it was faster in the moment, and paid for it two weeks later.
The Fix
Ripped out all name references. Replaced with user IDs.
Every team member now has an explicit mapping in a lookup table: their canonical identifier in each system, cross-referenced. When the automation needs to route to someone, it goes to the lookup table, not to a name match.
The lookup table took about twenty minutes to build. It would have taken twenty minutes when I built the original automation, too. I just skipped it.
Now when I onboard someone or when a system changes how it formats a display name, I update the lookup table. One place. The automations do not care. They are looking at IDs.
The Broader Problem
Every automation that routes by name is a bug waiting to be introduced.
Hire someone whose name is similar to an existing team member: your routing logic gets ambiguous. A person goes through a legal name change: every automation that referenced the old name silently breaks. You merge two tools and the display name format changes: the match fails, or worse, it matches the wrong person.
None of these are edge cases. They are normal organizational events. People join teams. People change names. Systems get consolidated. If your automation treats names as identifiers, every one of these events is a potential silent failure.
The fix is the same every time: use whatever the system uses internally. Not the display name, not the label humans see. The ID. The email address. The stable unique thing.
What I Check Now
Before any automation that involves routing or assigning work to a person, I ask three questions:
How am I identifying the person? If the answer is “by name,” I stop and find the ID equivalent.
Where does that identifier come from? If it comes from user input or a display field, I check whether it can collide with someone else’s identifier.
What happens when this fails silently? If the failure mode is “work disappears and nobody knows,” I add an audit step. Something that counts what was routed and surfaces the number somewhere I will actually see it.
The automation that got two people confused was doing genuinely useful work. It was routing correctly most of the time. The mistake was in not designing it to fail loudly when it could not make a clean match.
Confident and wrong is worse than uncertain and visible. Build automations that know when they are uncertain.
Blake Bailey runs Bailey Business Ventures, an AI transformation consulting practice. He now maintains a lookup table with the obsessive energy of someone who once watched twelve tasks disappear into the wrong person’s queue.