In short. A helpdesk chatbot is not judged on a deflection percentage, but on a list: the actions it is allowed to carry out on its own. Answering a question, opening a ticket, reporting its status: nobody argues about those. Resetting a password, unlocking an account, enrolling a new authentication phone: that is where internal support turns into a way in.
On 10 August 2026 we read the text of the nineteen organic results returned by Google France for the query « chatbot helpdesk ». Not one of them writes « social engineering », « phishing » or « identity theft », and not one cites France’s national cybersecurity agency. Yet that agency states in black and white that IT departments are being impersonated. This article fills the gap, with a proof-of-identity scale you can play with further down.
A helpdesk is the internal counter: the line an employee calls when their password stops working, when the printer on the second floor refuses to pair, when they need access to a tool they have never opened. That counter is buried under requests that repeat themselves, and the idea of putting a chatbot on it is as old as IT support itself.
The pages selling that idea all tell the same story: available at night, never tired, it absorbs tier one and hands time back to the technicians. That is true. It is not wrong, it is incomplete, and the missing piece has a precise name: none of it says who the bot is actually talking to.
A customer support chatbot picks the wrong answer and costs two minutes. An internal support chatbot that picks the wrong person hands a password to a stranger. This is not a textbook hypothesis: it is a modus operandi documented by France’s national cybersecurity agency in its annual threat report. This article takes the problem in that order: what the bot really closes, who it is talking to, and what proof to require before letting it act.
What a helpdesk chatbot really closes
Not every request arriving at an internal counter is the same, and mixing them up is the first scoping mistake. They fall into three families, which call for neither the same work nor the same level of trust.
The first family is requests to know: how to connect to the VPN from abroad, where to find the expense claim procedure, which phone model is eligible for renewal. Nothing to execute, nothing to verify: what is needed is a good answer, up to date, and the ability to say it does not know. This is the natural ground of a bot plugged into a knowledge base.
The second family is requests to record: report a fault, book a room, order a consumable, ask for the status of a ticket opened yesterday. The bot creates or reads an object in the ticketing tool. It opens no access, and the worst it can do is create a duplicate ticket.
The third family is of a different nature. These are requests for access: forgotten password, account locked after five attempts, a new phone to enroll as an authentication factor, rights to widen on an application. They are extremely repetitive, and therefore extremely tempting to automate. They are also the only ones whose failure costs not time, but access to the information system.
| Family of request | What the bot does | What has to be plugged in behind | Cost of a mistake |
|---|---|---|---|
| Know | It answers, or it admits it does not know | A knowledge base kept up to date, with dates | A stale answer, a procedure followed for nothing |
| Record | It creates, reads and updates a ticket | The ticketing tool, for both writing and reading | A duplicate, a miscategorized ticket |
| Access | It performs an action on an account, or refuses | The directory, the second factor, and a record of who decided | Access handed to the wrong person |
That third row is the subject of everything that follows. It also explains an oddity: when the large vendors describe their IT support agent, they stop right before it.
The scenario published by Microsoft has five steps: create the agent, answer internal policy questions, check a ticket status, hand over to a human, update the support documentation. Across the 658 words of the page recorded on 10 August 2026, the words « identity », « authentication », « password » and « reset » do not appear once.
This is not an oversight, it is a cautious choice: the scenario stays inside the « know » and « record » families. The problem is that the most frequent request at a helpdesk, the one that on its own justifies the project in the IT director’s mind, belongs to the third family. Nobody says how to handle it, and everybody handles it anyway.
A helpdesk chatbot and a customer support chatbot are not designed the same way. The second talks to strangers about whom almost nothing is known, and everyone accepts that. The first talks to people the company knows perfectly well, which creates the comforting illusion that it knows who they are.
Who are you talking to? The question the product pages skip
The internal counter has one property customer support does not: it holds the power to hand access back. That power is exactly what makes it a target, and France’s national cybersecurity agency, the ANSSI, has been documenting it for several years.
In its Panorama de la cybermenace 2025, published in March 2026, the ANSSI devotes a whole section to social engineering. It writes: « In 2025, the ANSSI observed the use of advanced social engineering techniques such as SIM swapping, MFA fatigue, identity theft and voice phishing by cybercriminal actors. » And, a few lines further down: « The ANSSI thus observed several cases of fake IT support scams, prompting employees to download RMM tools as the initial vector of compromise. »
The next passage is the most useful for anyone building a helpdesk. The agency describes French companies that were compromised, including luxury sector entities, and states: « In at least one of the cases, the attackers are said to have impersonated the IT department in order to obtain access to a customer relationship management application. »
Impersonation works in both directions, and that is what makes the subject hard. The attacker can pose as support towards an employee, which is what the ANSSI describes. They can also pose as an employee towards support, and politely ask for a password reset. A chatbot placed at that counter mechanically inherits both risks.
Voice phishing. The ANSSI defines it as a « malicious technique in which the attacker uses a telephone call to encourage the victim to disclose sensitive information or perform compromising actions, often by impersonating a trusted authority (IT department, bank, and so on) ». Moved to written chat, the technique does not change: only the channel does.
Two recent shifts make that impersonation easier than it used to be. The first is how ordinary synthesis tools have become. In its threat summary published on 4 February 2026, the CERT-FR notes that « many cybercriminals exploit deepfake services, for a few tens of dollars, for the purpose of identity theft ». A voice on the phone is no longer proof, and neither is a writing style.
The second shift is cultural. In its 2025 activity report, the French public service Cybermalveillance.gouv.fr ranks fake technical support scams fourth among threats to individuals, with 5.9 % of assistance requests and 18 000 cases handled, up 39 % year on year. In other words: your employees have been trained, in their private lives, to distrust anything that looks like IT assistance. They will apply that distrust to your chatbot, and they will be right to.
Assuming a corporate chatbot is protected because it lives behind the intranet. As soon as you publish it on WhatsApp, on a phone number or on an open support address, it becomes reachable by someone who has no account with you at all. The question is not where the bot is hosted, it is what the channel proves at the moment of the request.
The level of proof has to follow the cost of a mistake
The ANSSI offers no single recipe, and that is honest of it. In its guide Recommandations relatives à l’authentification multifacteur et aux mots de passe, published on 8 October 2021 and still current, the section on access recovery lists the possible methods, then explicitly declines to designate one.
The text lists « receiving a self-generated temporary password », « receiving a single-use temporary reset link » and « contacting IT support », then draws the line: these methods « come with their own problems: the choice of delivery channel (email, SMS, postal mail, telephone, and so on), the choice of validity period for temporary links, how complex these methods are for the user, whether or not a human verifier is added, and so on. This makes it very difficult to recommend any one method in particular. »
Recommendation R30 therefore does no more than require « an access recovery method suited to the context of use ». That is not a dodge, it is the real statement of the problem: there is no right level of proof in the abstract, there is a level of proof proportionate to what you are about to do. That is exactly what a helpdesk chatbot has to encode, and it is what the tool below turns into numbers.
How much proof should you require before the bot acts?
Four questions, a risk score out of 26, and the action the chatbot is allowed to take. The scale is published: every answer carries its own number of points.
What is being asked?
How is the requester recognized at the moment of the request?
Which account is involved?
What does the context of the request say?
The action gives away no access and changes nothing sensitive. The chatbot answers, opens the ticket, books the room. A timestamped record is enough, there is nothing else to check.
The chatbot can go all the way, provided it asks for live proof at the moment of the action: a second factor approved on a device already enrolled, never a code sent to the very channel that was just used to ask. If the proof fails, the request moves to a human, it does not quietly disappear.
The chatbot does everything that adds no human value: it qualifies, gathers the evidence, prepares the ticket and the decision record. But an identified technician is the one who presses the button, after an out-of-band check, for example a call back to the number already on file or an approval from the line manager.
At this level, automation becomes the weak link. The chatbot executes nothing: it takes the request, explains the procedure, opens the ticket and hands over. That refusal has to be written into the scenario, not left to the model’s judgment.
An indicative scale, to be recalibrated against your own security policy. It expresses one simple idea: the level of proof follows the cost of a mistake, not the convenience of the requester.
Three examples, computed with this scale, show how far the verdict moves without the request changing at all.
The same password, three times over
Reset
An employee asks for a password reset from a session already open on a company-managed workstation. Standard account, nothing unusual. The request is worth 6 points, recognition 0, account 0, context 0: 6 points out of 26, the bot handles it after strong re-authentication. That is the nominal case, and it is perfectly automatable.
Same request, but the requester has no session at all: they simply state who they are on an open channel, the account belongs to an administrator, and its authentication factor was changed five days ago. You move to 6 + 7 + 5 + 4, that is 22 points out of 26: outside the bot’s remit. The scenario has to refuse, explain and transfer.
A locked account, and the detail that changes everything
Unlock
Unlocking an account after too many failed attempts is worth 4 points, which makes it the least costly of the sensitive actions. From a session open on a personal device, on a standard account, you are at 6 points: the bot can do it after re-authentication.
Add a single piece of context, « several failed sign-ins on this account today », and the total moves to 9 points out of 26. The verdict changes: the bot prepares the file, a human approves. That detail is precisely what separates an absent-minded employee from an attempt in progress.
The rule that does the most damage when it is forgotten fits in one sentence: never send the proof to the channel that was just used to ask. A code texted to a requester who introduced themselves by text proves nothing at all, it only confirms that the person is holding the phone they have just used. That is exactly what the SIM swapping cited by the ANSSI defeats.
Wiring the bot without opening a door
Going from principle to a running chatbot takes seven decisions, in this order. The first three are taken before a single line of scenario is written.
- Count the real requests, not the imagined onesPull twelve months of tickets out of the ticketing tool and sort them into the three families. That sorting tells you what the bot will really absorb, and it often contradicts the steering committee’s intuitions.
- Write the list of authorized actionsThis is the founding document, and it fits on one page. For each action, the proof score required and what to do if the proof fails. Anything not on the list is refused by default.
- Choose the channel for what it provesA widget inside the intranet inherits the corporate session, and therefore an identity already verified. A consumer messaging app only proves possession of a number. Both are legitimate, for different actions.
- Feed the knowledge base, with datesThe bot answers what you give it. A procedure with no update date will become a wrong answer, and nobody will know when it stopped being true.
- Wire the ticketing before the directoryCreating and reading tickets delivers most of the value for almost no risk. Connecting the directory and the second factor comes afterwards, once the list of authorized actions is settled and the scenarios have run in production.
- Keep the way out to a human always availableNot only when the bot fails: at any time, on request. A bot that keeps the user in a loop is experienced as a manoeuvre, and it pushes people to bypass the official counter, which is the worst possible security outcome.
- Log the decision, not just the conversationFor every sensitive action: the score computed, the proof obtained, the person or the rule that decided, the timestamp. That is what lets you understand after the fact, and it is what the audit will ask for.
What the company gains
- Requests to know and to record leave the queue
- Technicians handle incidents, not passwords
- Every sensitive action leaves a usable record
- The security policy becomes executable instead of being a document
What the employee gains
- An immediate answer at ten at night on a Sunday
- An interlocutor who does not judge the question asked
- The same journey whatever the site or the country
- An explanation when the bot refuses, not a wall
What the law has required since 2 August 2026
The European artificial intelligence act, Regulation (EU) 2024/1689, has applied since 2 August 2026. Its Article 50(1) speaks directly to every chatbot, internal ones included.
Providers shall ensure that AI systems intended to interact directly with natural persons are designed and developed in such a way that the natural persons concerned are informed that they are interacting with an AI system, unless this is obvious from the point of view of a natural person who is reasonably well-informed, observant and circumspect, taking into account the circumstances and the context of use.
For a helpdesk the obligation is easy to satisfy, and it serves the subject of this article. Announcing that you are talking to a machine also gives the employee a way to recognize the official counter, and to distrust anything that does not look like it. An explicit welcome sentence, a name that does not pretend to be human, and a reminder of the address or number the company actually uses to contact its people.
Two reflexes complete the picture, without turning any of it into a project. The bot asks only for what it genuinely uses to handle the request, and nothing more. And logs containing identifiers or authentication material get a retention period decided in advance, not a default one.
Where to start, and what it costs
The right first brick is not the most impressive one: it is the one that handles the first two families of requests, with a way out to a human that actually works. It goes live quickly, it touches no account, and it produces the material you will need for the rest, namely the real list of what people ask for.
On a no-code platform such as Botnation for support, that first brick is built without development: intents, answers, a connector to the ticketing tool, and an escalation rule. Moving to the third family, on the other hand, is not an interface question: it is a security policy question, and it is settled with the team that owns it.
On budget, the order of magnitude for a platform can be read on the public grid: a free plan at 0 €, a Basic plan at 39 € per month, a Pro plan at 59 € per month, and an Entreprise plan on demand. These are platform prices, not project prices. Botnation publishes a no-code platform and builds bespoke chatbots for its clients, through the Entreprise plan and its chatbot creation experts; a helpdesk project is then quoted on request, because it depends entirely on the number of connectors and on the scope of the authorized actions.
A third-party agency remains perfectly legitimate, in particular if you already have an integrator working on your ticketing tool, or a very specific business process to model. The difference, when the team that builds is also the team that publishes the platform, lies in what comes after: there is no bespoke development to take over, and the account, the scenarios and the base stay in the client’s name, editable in the editor.
Frequently asked questions
Can a helpdesk chatbot reset a password?
Yes, provided the proof of identity is supplied at the moment of the action and not at the moment of the request. In practice: a corporate session already open, or an approval on a second factor enrolled in advance on a known device. What proves nothing is a code sent to the channel that was just used to write, or a series of questions about a date of birth and a manager’s name, two pieces of information an attacker obtains in minutes.
What is the difference between a helpdesk chatbot and a customer support chatbot?
The audience and the power. Customer support talks to people the company does not know, about subjects that rarely engage the security of the information system. The helpdesk talks to identifiable employees, but it can hand access back. That power is what imposes a proof scale, whereas customer support does without one most of the time. The understanding mechanism is the same in both cases: it is described in detail in our article on how chatbots work.
Do you need a language model, or are rules enough?
The two coexist very well, provided each is put where it belongs. A generative engine plugged into your documentation is excellent for the « know » family, because it absorbs the phrasings nobody anticipated. For the « access » family, the path has to stay a deterministic scenario: it is a chain of verifiable conditions, not a conversation. You do not delegate the decision to hand back access to a probabilistic model.
How many requests does a helpdesk chatbot really absorb?
No generic figure applies to your company, and trusting the ones printed everywhere amounts to buying a clothing size at random. The only honest calculation starts from your own tickets: sort twelve months of history into the three families and you get your theoretical ceiling. What is actually reached then depends on the quality of the knowledge base and on how clear the way out to a human is.
Does the chatbot have to say it is a machine?
Yes. The European artificial intelligence act has applied since 2 August 2026, and its Article 50 requires that people be informed they are interacting with an AI system, unless this is obvious from the circumstances. On a helpdesk it is good practice anyway: an internal counter that announces itself is a counter people can recognize, and therefore distrust when a copy takes its place.
Can the helpdesk be opened on WhatsApp or by phone?
Yes for the « know » and « record » families, which gain enormously from being reachable where employees already are, especially on industrial sites and on the move. No, as things stand, for actions that touch access: those channels only prove possession of a number, and the SIM swapping cited by the ANSSI targets exactly that possession. The same bot can serve both audiences, provided the list of authorized actions depends on the channel.
What to take away
A successful helpdesk chatbot is not a bot that answers everything. It is a bot whose permitted actions are precisely known, and which refuses the rest in a predictable way.
Four questions to ask before launching the project, or to ask the supplier proposing it to you.
- What is the list of authorized actions, and what happens to everything that is not on it?
- What proof of identity is required for each one, and through which channel does that proof arrive?
- What happens when the proof fails? A transfer to a human, or a silent dead end that will push the user to bypass the counter?
- What is in the logs six months later: the conversation alone, or the decision, the proof and the timestamp?
An internal helpdesk that also handles human resources requests raises exactly the same questions, with data that is more sensitive still: the subject is developed on our page dedicated to the HR chatbot, and setting up a complete internal counter in our article on the chatbot for companies.
Build the first brick this week
Create a chatbot for free, plug it into your internal procedures and watch what your teams actually ask it. That list, and nothing else, is what will tell you where to draw the line of authorized actions.
Sources: ANSSI, Panorama de la cybermenace 2025, legal deposit March 2026, ISSN 2970-8818, page 30; ANSSI, Recommandations relatives à l’authentification multifacteur et aux mots de passe, guide ANSSI-PG-078 version 2.0, published on 8 October 2021, section 4.7 and recommendation R30; CERT-FR, L’IA générative face aux attaques informatiques : synthèse de la menace en 2025, 4 February 2026, TLP:CLEAR; Cybermalveillance.gouv.fr, Rapport d’activité 2025, page 52; Regulation (EU) 2024/1689 of 13 June 2024, Article 50 and Article 113, English text of the Official Journal of the European Union; Microsoft Adoption scenario library, « IT helpdesk agent » entry, consulted on 10 August 2026; pricing and support pages of botnation.ai, consulted on 10 August 2026. The four ANSSI, CERT-FR and Cybermalveillance sources are published in French only and the translations are ours. The reading of the nineteen organic results for the query « chatbot helpdesk » was carried out on 10 August 2026 on Google France.
