Turning On a Recruiting Chatbot Should Be Hard
A chatbot with nothing true to say will still answer a driver''s question about pay. The fix is not a better model — it is refusing to switch on until somebody has filled it in.
There is a specific failure that happens to almost every carrier who turns on a recruiting chatbot, and it happens in the first week.
A driver messages the company page and asks what the pay is. The bot answers. The number is wrong — not maliciously, not hallucinated out of nothing, just assembled from generic industry knowledge because nobody ever told the bot what this carrier actually pays. The driver takes that number to a recruiter three days later and the conversation starts from a position nobody chose.
TL;DR
- A chatbot with an empty knowledge base does not stay silent. It improvises.
- Pre-filled placeholder settings are worse than blank ones, because they make an unconfigured bot look configured.
- The safeguard is a hard requirement: no grounding, no switch.
- Enforce it at the database, not in the interface, or every other entry point bypasses it.
Why an empty bot is more dangerous than no bot
Language models are built to answer. Give one a system prompt with no carrier-specific content in it and ask about pay, home time, or equipment, and it will produce something reasonable-sounding drawn from everything it has ever read about trucking.
That output is fluent, confident, and unconnected to your business. It is also being sent under your carrier's name to a professional driver who will make a decision based on it.
The uncomfortable part: this is not a model quality problem. A better model produces a more convincing wrong answer.
The placeholder trap
Most recruiting chatbot setups ship with helpful defaults. A greeting is pre-written. The persona has a name. There are four example offers in the offers list — Company Driver, Owner Operator, Lease to Own, Team. The auto-schedule message is filled in.
The intention is to make setup feel easy. The effect is that the first time anyone saves the settings page, all of those placeholders are written to the database as if they were real. A carrier that has typed nothing now has a bot that looks fully configured — greeting present, offers present, ready to switch on.
The offers list is the sharp edge. If a bot's knowledge consists of four generic position names, it has enough to sound informed and nothing to be accurate about.
Rule: nothing a bot will say to a candidate should ever be pre-filled. Behaviour settings — tone, language, working hours, escalation keywords — can and should have sensible defaults, because the bot never states those to a driver and blanking them only makes escalation fail quietly. Content is different. Content must be typed by somebody at the carrier.
What "ready" should require
A defensible readiness gate asks for five things before the bot can be enabled:
- Company name — the bot has to know who it works for.
- Bot display name — drivers should know who they are talking to.
- A greeting — written by the carrier, not inherited.
- At least one knowledge document or one filled-in offer — this is the one that matters. Without it, the system prompt carries no knowledge section at all, and every question about pay and equipment is answered from nothing.
- At least one prescreening question — otherwise the bot is a conversation with no purpose.
Four of those are hygiene. The fourth is the safeguard.
Enforce it in the database, not in the form
A readiness check implemented in the settings screen protects exactly one path: a person using the settings screen.
It does not protect against an API call, a seeding script, a bulk import, an integration written next year, or a webhook handler that creates a conversation with the bot flag already set to on. Each of those is a real way carriers end up with an unconfigured bot talking to drivers, and none of them go through the form.
The check belongs on the table itself, as a constraint that fires no matter which path writes the row. Same rule, every entry point, permanently.
Two related details are worth getting right at the same time:
- After-hours settings must not be able to enable a bot. After-hours narrows the window of a bot that is already on. If it is read before the master switch, an after-hours row can start a bot whose main switch is off.
- New conversations must not default to bot-active. If the message handler sets that flag when it creates a thread, every new inbound conversation arrives switched on regardless of configuration.
Say what is missing, not that it failed
The last piece is a user experience point that turns out to be a safety point.
When the switch is refused, "Failed to save settings" teaches the operator that the system is broken and to look for a way around it. The system already knows exactly which fields are missing. Show them: name the requirement, mark the field, and link to the tab where knowledge documents and prescreening questions live.
An operator who is told "you need a greeting and at least one offer or knowledge document" fixes it in four minutes. An operator who is told the save failed opens a support ticket, or finds another route into the same table.
What this looks like in practice
The result is a bot that is slower to turn on and safe to leave running. It only knows what the carrier told it, which means the failure mode changes from a confident wrong answer to an escalation to a human — which is the correct behaviour when a driver asks something the bot has not been given.
Fleegital enforces exactly this: the bot cannot be enabled without company name, display name, greeting, at least one knowledge document or filled offer, and at least one prescreening question — enforced by a database trigger, so no interface, script or integration can bypass it.
Key takeaways
- An ungrounded chatbot does not decline to answer. It invents a plausible one.
- Never pre-fill anything the bot will say to a driver. Pre-fill behaviour, never content.
- Grounding — one real knowledge document or offer — is the requirement that does the work.
- Enforce readiness at the database so every write path is covered, not just the settings screen.
- When the switch is refused, name the missing fields. A clear refusal gets fixed; a generic error gets routed around.
Tagged
