The Chatbot That Announced Every Date One Day Early, a Time-Zone Debugging Story

Published 6 July 2026 · Last updated 7 July 2026 · Client engagement · Training provider, Cyprus

A chatbot that fails silently is worse than no chatbot. A broken one at least tells you it’s broken. This one looked completely fine, and that was the problem.

The situation: a bot that looked fine, and wasn’t

A training provider we work with runs a website chatbot that answers course questions and captures leads. It handled the load, it read well, everyone assumed it was working. Then we looked at the logs.

On 11 June, the COO of a real prospect company typed, in caps, “HOW TO I PAY.” The bot answered the question conversationally, helpfully, even, and never fired the lead form. No form, no CRM ticket, no follow-up. A qualified inbound, a COO with intent to pay, simply evaporated. And nobody noticed, because that’s the defining feature of a silent failure: it produces no error. Just a lead that quietly never exists.

That wasn’t the only thing wrong. The bot was quoting every course date one day early. And when it didn’t know a course’s hours, it invented them, it once told a visitor a GDPR course ran “09:00 AM, 05:00 PM,” a time that existed nowhere in the system. A bot confidently making up facts to a prospect is not a small problem.

Three bugs, three real root causes

We did a full audit and rebuild across the automation workflow and its CRM tool sub-workflows. The three failures each had a genuine cause underneath, not a surface glitch.

The off-by-one dates. Full-day events stored their timestamp at Cyprus local midnight, saved as UTC, which is 21:00 or 22:00 the previous day. The tools were handing that raw timestamp straight to the AI, so “starts 15 June” quietly became “starts 14 June.” The fix normalises every date onto the Cyprus calendar before the model ever sees it. That one is now written on the wall: if a tool ever emits the raw timestamp again, the bug is back.

The invented hours. The model was filling knowledge gaps from its own memory, the single most dangerous habit an AI in production can have. Course hours live in exactly one place in the system, and nowhere else. We wired the tools to pass that value through explicitly, and added a hard rule to the prompt: never fill a gap from memory. No data, no answer. A bot that says “I don’t have that, let me connect you to someone who does” beats a bot that confidently makes something up, every time.

The lost leads. The lead trigger didn’t recognise payment intent, so “how do I pay”, one of the highest-intent things a visitor can possibly type, sailed straight past it. We added a deterministic keyword net (in English and Greek) so payment questions now always fire the form. We also caught the mirror bug: after a visitor had already submitted the form, the bot would turn around and re-ask for their contact details, it did exactly that to one lead on 4 June. The lead prompt is now suppressed for the rest of a session once the “an advisor will be in touch” confirmation is in the conversation.

While we were in there, we found the lead-scoring logic quietly cheating itself: it was counting the bot’s own use of the word “advisor” as a buying signal, and it once awarded a “valid work email” bonus to a lead whose email field actually contained the visitor’s chat question. The scorer now counts only what the visitor says, and requires an actually-valid email before it trusts one.

The part that makes engineers wince: the deploy trap

This is the detail every automation engineer will recognise. The platform runs a draft/published split, the workflow the editor shows you is not the one production runs. We edited the workflow, restarted the container, and nothing changed. Executions kept running the old version, because the runtime loads the published copy, not the draft you’re looking at.

Getting a change to actually deploy took three iterations, including hitting a trap where a single pair of curly braces in the agent’s prompt gets parsed as a template variable, throws an error, and kills the agent, so the bot returns an empty reply. Silent again. If you don’t know these traps exist, you “fix” a bug, watch it persist, and slowly lose your mind. Knowing they exist is most of the battle.

What changed

We built a 17-scenario customer test suite, browsing in English and Greek, topic and hours lookups, fuzzy course-name matching, price and enrolment objection handling, prompt-injection attempts, off-topic questions, nonexistent courses, and three real lead submissions including the junk-email regression. Fifteen of the seventeen passed on the first run; the other two were fixed the same day.

The exact failure that lost that COO is now a permanent test case, it can never silently come back without a test going red. Payment questions convert. The bot is honest by default: no fabricated dates, no invented hours, and when a course isn’t scheduled it says so plainly before offering alternatives. And there’s always a human one message away, a typed “talk to a human” path hands complaints, refunds, invoices, and access problems to a colleague and logs a ticket, instead of the bot improvising.

One last fix earned its own line. The Greek follow-up copy had said something that, read literally, came across as “so we can surveil you.” We changed it to a plain “we’ll be in touch.” Small words, on a page a prospect reads at the exact moment they’re deciding whether to trust you.

The takeaway

The lesson here isn’t “AI is unreliable.” It’s that AI in production needs the same discipline as any other serious system: real tests, honest failure modes, and a human always one message away. A chatbot that goes down is an obvious problem someone fixes by lunch. A chatbot that quietly drops your highest-intent leads and invents facts to prospects is the expensive kind, because everything looks fine right up until you read the logs.

What’s the silent failure hiding in your funnel right now? Book a free discovery call and we’ll help you find it before it costs you another COO.

Related service: AI Chatbots