Key takeaways
- We asked a calendar for the bookings inside a window. It accepted the window, ignored it, and returned the whole day.
- Our code took the first result, so "who am I meeting right now" was answered with whoever had the earliest booking that morning.
- Six meetings over five days were filed on the wrong people: ten tasks and four notes on four contacts who were not in those calls.
- It hid for two weeks because a guess and a proven match were stored identically.
- A filter you sent is not a filter that was applied, and confirming that costs one request.
Our meeting recorder is supposed to know who you are talking to before you say hello. It reads the calendar, finds the booking covering right now, and pulls up that person: their record, their open tasks, the notes from last time. When it works it is the best thing in the app. For two weeks it was confidently, invisibly wrong.
The request that was ignored
The lookup is the obvious one. Ask the calendar for events between a few minutes before now and a few after, and whatever comes back is the meeting.
The calendar accepts a start time and an end time. It documents them. It returns a response that looks correct. It does not apply them. We proved it once we were suspicious: a forty minute window around half past four came back holding that morning's half past nine booking and a three o'clock one. Neither is in the window, nothing warned, and the response was well formed.
Then our code took the first item in the list, which is how the answer to "who is on this call" became "whoever was booked first today".
This is nasty rather than obvious because it is usually right. Most days the earliest booking is the only one, or it is the meeting you are in. The bug shows up on busy days, which are the days the notes matter.
What it actually cost
Six meetings across five days were attributed to the wrong person, and that is not a wrong label on a recording. The recorder does real work off that identity: it writes the call's action items onto the contact as tasks, and leaves a note saying a meeting happened.
So ten tasks and four notes went onto four people's records, describing conversations they were never part of. One was a task about a payment detail belonging to a different business, sitting where any administrator with account access could read it. That is not a display bug. It is other people's information in the wrong file.
It stayed invisible for a fortnight for one reason. A match from a confirmed email address on the invitation was recorded as a match. A guess from a nearby time slot was recorded as a match. Same word, same field. Nothing separated the certain from the guessed, so a systematic error looked like normal operation.
Filtering the window was half the fix
The immediate repair is small: filter the window ourselves after the response comes back, and pick the booking nearest the meeting rather than the first in the list.
Then we turned it back on and found it still building confident identities out of very little, so four more things had to change. These are the ones worth stealing.
Say how it matched, and keep saying it. A booking whose span actually contains the moment is evidence. One that merely starts nearby is a guess. Flattening both into one word is what let this run for two weeks.
An unknown duration is a point in time, not an hour. With an end time missing we assumed an hour, so a half past nine booking claimed to still be running at quarter past ten and swallowed the meeting that actually was.
A partial failure is not an absence. When one of several calendars timed out, the one that answered looked like the only booking in the slot, which reads as certainty. That result is now marked incomplete and treated as ambiguous.
And weak evidence may label but never write. A guess can put a name on the screen for a human to confirm. It cannot create a task on somebody's record. That check is a whitelist of match types permitted to write, so anything new fails closed instead of inheriting permission.
The same mistake in a different coat
The popup that asks whether to record resolved identity as of the moment it appeared, not the meeting's start. A two o'clock meeting prompted at ten past searched ten to two until half past, a window that no longer holds its own booking and does hold the quarter past appointment for somebody else.
Anchor to the time of the thing that happened, never to now. Any lookup about a past or ongoing event that quietly uses the current clock is right in testing, where everything happens instantly, and wrong in production.
Cleaning up cost more than the bug
Fixing the code took an afternoon. Repairing the records took longer and needed its own tool: find every task and note written from the affected meetings, move the tasks somewhere internal so nothing real is lost, then delete the misplaced copies and read each one back to confirm it is gone. A delete that reports success and does nothing is the kind of thing that got us here.
That ratio is normal for identity bugs. The write is cheap and the unwind is not, which is the argument for refusing to write on weak evidence at all.
What this means for your business
Any system that says this belongs to that customer is doing a lookup, and it can be wrong in ways that look right. Call recordings attached to contacts, forms matched to records by phone number, review requests sent after a job.
Two questions are worth asking about each. When it links something to a customer, does it record why it was sure, or only that it was? And if it was a guess, may that guess write to the record, or only suggest?
The rule underneath is worth more than either. A filter you send is not a filter that was applied. Check the other system did what you asked before building on top of it. For any GHL consultant Bay Area setup we touch, that check is one request and the cheapest hour in the build.
Want this built for you
We build CRM systems and automation that know a match from a guess. Start at optechsol.llc.