A service company that assists its customers around the clock, in several languages, receives about five thousand calls a month. Its terms of service promise updates every few hours on open cases. On the phone that promise stayed on paper: operators said they would call back, then waited for the customer to call again. When the company decided to hand first-line support to a virtual agent, the discussion soon moved from the answers to the rules. Who updates them after go-live, and how customer requests are measured, matter as much as the initial set-up.
Who changes a virtual agent’s rules after go-live?
The company, on its own: a rule written in a document is updated by replacing the source, and an agent instruction is edited and republished.
A typical case is a deadline that changes, for instance a refund that moves from 48 to 96 hours. A virtual agent’s rules can live in two places. First comes the knowledge base. The platform rereads a web page, internal or public, automatically every 24 hours, while a PDF is replaced with the new version and takes effect immediately. The second place is the agent’s configuration, where the rule appears as a natural-language instruction: the text is edited, saved and republished.
Changes that affect an entire branch of the flow, such as a new request category, are possible with administrator access. In that case they are best assessed with whoever built the flow, because a change upstream affects every answer downstream. How to build the knowledge base before launch is covered in the article on the knowledge base for AI agents.
Forbidden answers follow the same logic. A virtual agent must not estimate firm dates, promise refunds, assign responsibility or invent the status of a case. These restrictions are written in the knowledge base or in the agent’s description, and the person running the service updates them without opening a request to the supplier.
Transcripts or audio recordings: what should be kept?
Transcripts can be searched and exported; audio adds to the cost, depends on the phone system and cannot be queried like text.
At the service company described above, the owners wanted the audio of every call to be kept as well. At first the question looked technical, tied to storage space and retention time. The service manager shifted the discussion with a practical question, namely who would listen to those recordings.
The answer came from analysing the existing history. Going back over the conversations handled until then, the company found wrong answers that had been repeated over time without correction. The recordings were already there; what was missing was someone rereading them at a fixed interval.
Userbot stores transcripts of every conversation, which can be exported in bulk at any time. Audio depends on the phone system and does not lend itself to searching: to find a sentence, someone has to listen. The company chose transcripts only, kept for three months, with quarterly checks on a sample of conversations. Before closing the point, the operator who currently replays audio at shift changes needs to be involved, to understand what she takes from the audio and how to carry it into the text.
Retention rules apply both to conversations with the agent and to those handed to an operator. The period is agreed with the privacy adviser, in light of the storage limitation principle set out in the GDPR.
Who runs the agent after go-live
At the service company, the team that will run the service once it is live comprises four operators and one or two people in the administrator role, including the technical lead who followed the project. The administrator owns the instructions and the forbidden answers; operators take over the conversations handed on by the agent. Whoever writes the procedures keeps the knowledge base, and sample rereading takes place every quarter. The internal time required depends on volumes and is estimated during the analysis, together with the scope.
Insight: the errors that came to light dated from the history of the existing service, run by operators. With a virtual agent every conversation becomes searchable text, and sample rereading becomes an activity that can be scheduled like any other.
How can a company measure what customers ask the virtual agent?
It is measured with a router agent, which assigns every request to a category designed by the company, and with a counter for each category.
Counters show where to act. A growing category points to information to clarify in the knowledge base, or to a step to hand to an operator, and it reduces calls repeated for the same reason. To get the counters, the company builds a router agent that classifies each request into a category, even when the customer does not use the expected words. Each category is linked to a counter, which appears in reports like any other variable. When requests in a category increase, a second router splits it into subcategories. This is the most common set-up in projects built on this platform.
Alongside categories there is emotional state. The agent detects whether the person writing is calm, dissatisfied, angry or agitated, and the information is visible only to the company. With a high level of agitation an operator can take over. The limit should be clear from the start: the system detects dissatisfaction but does not link it to a cause. If wrong information in the knowledge base causes frustration, tracing the cause remains the company’s job, starting from the counters.
Standard dashboards show how many messages the agent handled, with what accuracy and how many needed a human; others are built on the company’s own indicators. From the same dashboard an operator takes over a conversation in real time, and the customer sees the operator’s name appear.
Overnight filtering prepares the morning’s work
A company that installs and services home mobility aids, with customers who are often elderly, receives about 3,500 interactions a month on a single WhatsApp number. Technical support, invoices, administration and sales enquiries all arrive at the same point. A fault reported at ten in the evening used to turn, by the next morning, into a long string of messages to piece together. The service manager had a precise request: to be able to count on the agent treating customers the way the staff did.
The analysis showed that about two breakdowns in three have a recurring cause, already described in the engineers’ service reports. So the virtual agent collects the details of the report and sends the maintenance manager a pre-filled email, with a likely cause drawn from those reports. If no operator answers within a set time, thirty seconds for example, the conversation returns to the agent, which completes the data collection.
The choice was to proceed in phases. Phase one starts with the simplest and most frequent need, sending invoices on request, with a read-only connection to the ERP. The router that sorts requests by department comes later, once the conversations collected have shown the recurring patterns. The router’s categories thus come from the requests collected in the first months of service.
Can a virtual agent update the customer without waiting for a call back?
Yes, on text channels: a recurring block periodically checks the status of the case and sends the update, by email if the chat has closed.
At the service company described at the start, the promise of regular updates became a function of the agent. The website chat keeps its memory as long as the session stays active. For this reason the agent asks for an email address at the end of the conversation, and a recurring block checks the case status every three hours and sends the update. The same pattern applies to requests that arrived by phone.
Timing rules are best kept in the CRM or ERP: the business system generates the alert, and the agent writes the message. That way the deadline lives in one place, and whoever changes it does not need to remember to update the agent too. Connecting language models with business systems is the subject of the article on AI on company data.
The company chose its supplier and, before the contract, asked for a two-day preliminary analysis to fix the scope. The move of the phone system is planned for one of the exit windows of the current telephony contract. Configuration takes a few weeks, while the changeover itself happens at an agreed moment, with minimal disruption.
A virtual agent in service: the checks for the first quarter
The table summarises where each element of a live agent sits and who updates it.
| Element | Where it sits | Who updates it |
|---|---|---|
| Operational information | PDFs and web pages in the knowledge base | The service lead, independently |
| Instructions and forbidden answers | Agent configuration | The administrator, who saves and republishes |
| Flow branches and categories | Routers and flows | The administrator, together with the partner |
| Transcripts | Conversation archive | Rules set with the privacy adviser |
| Update deadlines | CRM or ERP | The department that owns the case |
In the first three months of service it is worth checking:
- which rules sit in the knowledge base and which in the agent’s instructions;
- who has administrator access and which changes call for a discussion with the partner;
- which answers are forbidden and where they are written;
- how long transcripts are kept, and which check would justify keeping audio as well;
- which categories the router uses and which counter is read every week;
- which level of agitation hands the conversation to an operator, and within how many seconds the operator must respond;
- where the deadlines for proactive updates are held;
- who rereads a sample of conversations, and how often.
Virtual agents with Aesir, from the flow to the phone system
Aesir Srl designs virtual agents on Userbot for chat, WhatsApp and voice, within its Intelligence business unit, and connects them to the Wildix phone system and to business applications. Aesir is a Gold Partner of NTS Informatica for Business Experience, and with other ERP systems available connectors are used or new ones are built. The platforms we select process data in EU data centres with certifications from the ISO/IEC 27001 family and requirements in line with NIS2: the same standards applied to our own infrastructure. We run projects across Italy and, on specific request, in Switzerland, the United Kingdom and the United States.
Frequently asked questions about a virtual agent in service
Can the company change one of the agent’s rules on its own?
Yes: a knowledge base document is replaced, and an instruction is edited and republished in a few steps. Changes to an entire branch of the flow are best assessed with the partner.
How long are conversations kept?
The transcript history remains available according to the chosen plan and can be exported in bulk at any time. The retention period is set with the privacy adviser, both for conversations with the agent and for those handed to an operator.
Does the agent recognise an angry customer?
Yes, it detects the emotional state of the person writing and makes it available as a variable. With a high level of agitation the conversation can pass to an operator.
What happens if no operator is available?
The conversation returns to the virtual agent, which collects the details and prepares the request for the right department. The waiting time before the handback is set in the configuration.
Let’s talk
A virtual agent improves over time when someone in the company has the job of rereading its conversations and updating its rules. That responsibility is assigned before go-live, together with administrator access. If you would like to explore the subject or assess the situation in your own company, you can fill in the form at the bottom of this page or write to support@aesir-tech.it: we will arrange a free consultation and start from your numbers.