The hard part of this project was not writing a bot. The hard part was stopping it from making things up. Character Park already had an AI assistant built by someone else, and invented answers were exactly why people stopped using it. Below is how we built the replacement: where the job came from, why week two went off plan, what had to be rewritten, and how it ended. With correspondence, screenshots and the client’s own verdict at the end.

How they found us and why they chose us

Character Park is a resort in Kriukivshchyna near Kyiv: cabins and chalets, two pools, a restaurant. They found our bot-development listing on a classifieds site and got in touch themselves.

Three vendors made their shortlist. Most of their questions were not about price but about what happens after launch: who fixes mistakes, how fast, and whether they could edit the content themselves. That decided it. We were not the cheapest option, and the client said so directly in writing.

Their director wanted to agree terms in person — «find the best version of our bot system, agree the price and start working». We met in central Kyiv and closed scope and price within an hour.

What came before us

It is rare to get the predecessor described by the client themselves. After launch, while discussing the testimonial, their manager explained why the old bot never stuck:

Three complaints in one sentence: it does not advise, it confuses its own information, and errors never get corrected. The first two are about answer quality; the third is about process. Technically it meant the bot could not be repaired — there was no way to control what it knew, and nobody whose job it was to do so.

What we built

A Telegram assistant on aiogram 3, with a knowledge base of eight client documents — roughly 71,000 characters covering cabin descriptions, rules, the restaurant menu and booking terms.

• PostgreSQL 16 with pgvector — main database and vector store in one service, no separate vector DB to operate
• RAG retrieval over the knowledge base, with reranking on top
• GPT-4o-mini as the primary model, Claude Haiku as a fallback if it is unavailable
• Redis — conversation state, rate limiting, caching
• Streamed replies via message editing, so text appears progressively instead of after a five-second silence
• An admin panel for owners and managers, so content changes never require a developer

We covered the general approach to this kind of work separately, in the piece on AI chatbots for business and in the one on where AI actually pays off.

Where it went off plan

The MVP came together in about two weeks. And then the exact problem that had driven the client away from the previous vendor showed up: the bot hallucinated. Not wildly — but it quoted inaccurate cabin prices, mixed up conditions, and asked for clarification where it should simply have answered.

Fixes and rework took another one to two weeks beyond plan. We did not bill for that time — the fault was in our architecture, not in changed requirements.

The fix: a separate facts layer

Instead of relying on document search alone, we added structured facts — short verified statements injected into the model’s prompt as authoritative data. The model no longer recalls things from prose; it is handed them.

1. 1

   Classify the question

   First determine category and intent: a question about a cabin, the pool, the rules, the restaurant.

2. 2

   Pull the facts for that category

   The resolver takes facts from that category only. Small categories go in whole — seven rules-related facts cost nothing.

3. 3

   Filter by relevance on large categories

   The cabins category holds 79 facts, about 5,700 tokens. Dumping all of them buries the one or two lines that matter. Above a threshold of 25 we keep only what is relevant to the question.

4. 4

   Protect the baseline guarantees

   Facts that apply to every cabin — "every house has a hairdryer", "each one has a grill" — are always kept. Otherwise "what amenities are there?" could drop a guarantee purely because the wording did not match.

The facts themselves were not written by a developer. The client already had everything on hand, sent it over, and we implemented and reindexed it. They now edit those facts through the admin panel on their own.

Prices that cannot be invented

The other half of the problem is that prices and availability change daily, so keeping them in a document is pointless. The bot is connected to EasyMS, the park’s booking system, and reads live data from it. Documents answer "what is this"; EasyMS answers "what does it cost and is it free".

The integration is read-only — nothing is ever written into their system. It caches its auth token in Redis, retries transient failures on a fixed schedule, and treats a Cloudflare block as its own distinct error, so a problem on their side never turns into a quietly wrong answer.

What working together looked like

Promises say less about a collaboration than the way mistakes get handled. The pattern was the same every time: the manager reports a problem, we respond the same day, they verify it against real guest questions.

The outcome

The bot now takes a guest from first question to a decision: it understands the size of the group, matches a cabin to the party and the date, calculates the price including extra guests, and hands over the next step.

The park launched the bot publicly and introduced it to guests on Instagram as another member of staff, available around the clock. Roughly 500 users in the first week.

What the client said

We asked the contact centre manager for a detailed testimonial. Published in full, unedited, translated from Ukrainian:

Frequently asked questions about this project

In short

• The client came to us after a failed AI bot from another vendor: "it did not advise at all, the information got mixed up, mistakes were never fixed".
• They picked us from three vendors and not on price — the deciding question was post-launch support.
• MVP in two weeks, then one to two weeks of rework because of hallucinations. We did not bill for it.
• The fix: a structured facts layer in the prompt, plus live prices and availability from the booking system.
• The client edits the content themselves through an admin panel — precisely what the previous solution lacked.
• Result: around 500 users in the first week, and the park introducing the bot on Instagram as "another colleague".