After Launch: Managing an AI Agent Through the First 90 Days

The question people ask before buying an AI agent is what it costs. The question worth far more, and one almost nobody asks, is who looks at the agent in week three and what exactly they check there. An agent that has gone live is not a finished project but a new employee on their first day: it knows the script, it does not yet know your customers, and the gap between the two closes only against real enquiries. This article is about what happens after the launch call - which numbers to read, what counts as a fault and what counts as a change, and how much work this actually takes each month.

The first month is part of the product, not a bonus

We have written before about the ten tests an AI agent should pass before it talks to customers, and that is where lab-condition work ends. What internal testing cannot produce is the way real people write: with typos, with abbreviations, with a forty-second voice message instead of three sentences, and with one question that contains three. Above all, customers ask things you never considered, because they do not know your business the way you do.

That is why the first month after go-live is designed as a tuning period. On top of the regular monthly changes it includes revision rounds, and their number depends on the plan. A round works off a single consolidated list - you collect all your notes into one list and send it, we handle the whole list and push it live within three business days. That sounds formal, but the reason is practical: one list of twelve notes closes faster than twelve messages arriving separately over a week, because you can see where two notes contradict each other before fixing either.

One detail of the timeline is worth noting: the monthly subscription starts on the day the agent goes live, not on the day the setup fee was paid. The first month of tuning is a paid month of a product that already works, not a waiting period you pay for.

Four numbers worth reading every week

Half an hour a week in the WhaleBiz CRM is plenty, provided you know where to look. These are the four numbers that explain almost every problem you will run into:

• The share of enquiries that closed with a complete record. The standard enquiries table we set up has ten fields: name, phone in E.164 format, email, source, status, owner, AI summary, service, next step and notes. An enquiry closed with three fields is not an enquiry, it is a name and a phone number. When that share is low the cause is almost always one of two: the agent asks too many questions before delivering any value, or it asks them in the wrong order.
• The handoff rate to a human, and above all its breakdown. The number alone says nothing, and there is no single correct figure that fits every business. What matters is whether the same reason repeats. A handoff that happens once is an incident; a handoff that happens thirty times on exactly the same question is a change waiting to be written.
• What arrives outside business hours. The share of enquiries that come in after six in the evening, at weekends and on holidays is usually the number that justifies the entire investment, and it is almost always higher than owners estimate in advance.
• The list of things the agent did not know. This is the most valuable list in the system and also the one most often ignored. Every question the agent could not answer is a real gap in the business's knowledge, and often a gap that human employees each fill in their own way.

There is a fifth number, less dramatic but worth money: message consumption against the quota. Each plan has its own monthly quota and its own overage rate. One message means one agent reply. The customer's incoming messages are not counted, and a reply to a voice message, an image or a file counts exactly like a reply to text - there is no media multiplier.

Fault, change, or new development

The distinction sounds bureaucratic right up to the moment it saves an argument. Most dissatisfaction with automation vendors comes not from the price but from the fact that nobody defined in advance what is inside the subscription and what is outside it:

Two rows deserve emphasis. The first is that the number of times your automations and follow-ups run is neither metered nor billed - we have no trigger meters, and that is precisely the difference from platforms selling monthly packages of operations. The second is the rule that governs every bottom row: we never start paid work before the price has been stated and you have approved it. The full detail, including exactly what the setup fee buys, is on the what setup and support include page.

How many changes a month a business really needs

The quota depends on the plan. The pattern that repeats almost every time is a falling curve: in months one and two the quota is used in full, sometimes along with the revision rounds, and from month three two or three genuinely necessary changes remain - a price update, a seasonal promotion, a new service.

Three small habits reduce consumption without giving anything up. First, batch: one change can cover several fixes in the same request, so it is better to collect notes for three days and send one list. Second, use what is open to you: automations, follow-up rules, fields, tables and views are things you change yourself in the interface, unlimited and uncounted. Third, do not spend a change on a fault - if something simply does not work, that is a free and unlimited fix.

If after three months you still hit the quota every month, there are two possibilities. Either the business genuinely changes a lot, in which case extended support adds extra changes and a faster response, and can be added or removed at any time. Or, and this is the more common case, something in the underlying script is inaccurate and you keep patching it at the edges. In the second case it is better to stop and fix the root.

The knowledge base goes stale, and that is what trips the agent up

Almost every case of an agent giving a wrong answer is originally a content problem, not a model problem. A price list that was updated and never uploaded, a service you stopped offering, holiday opening hours, a form that was replaced. The size of the knowledge base is set by plan, and for most businesses that is ample, because one well-organised document is worth more than ten overlapping files. We covered the right structure in our guide to building a knowledge base for an AI agent.

What you do need is a routine. Once a quarter go over the price list and the service list; once a month go over the list of questions the agent could not answer and decide which of them become content. Before holidays, update hours in advance rather than the day after.

One point about behaviour is important to understand: when something is not in the knowledge base, the agent says it does not know and hands over to a human instead of guessing. That is a deliberate decision, not a technical limitation. In sensitive fields it is absolute - the agent does not diagnose, does not give medical or legal advice, and hands over to a human the moment the conversation goes there. A confident wrong answer costs far more than an answer that admits it does not know.

When to expand, and when it is still too early

After three months you have something you did not have before: data on how your customers actually behave, rather than estimates. That is the right basis for expansion decisions, and there are three real triggers.

The first is the channel. If customers keep asking to move to WhatsApp and you are on Start, which covers a website widget or Telegram only, the plan simply no longer fits. WhatsApp through the official Meta API and calendar booking begin at Standard. The second is capability: in-chat payments, Instagram and Facebook, a team with separate permissions, several calendars, or an API and webhook connection sit in Business, with several agents. The third is arithmetic: if you pay overage every month, the included per-message price falls as the plan rises, and it is worth running that comparison instead of paying overage out of inertia. All prices are on the pricing breakdown and exclude VAT.

A fourth trigger, less obvious, is when a single agent starts serving two genuinely different goals. A sales agent that qualifies a need and books a meeting and a service agent that answers existing customers about order status are two roles with a different tone, a different knowledge base and a different success metric. Trying to compress both into one script produces an agent that is mediocre at both, which is why an AI agent for service and support is defined separately from the sales agent.

A word on direction: we are building towards an autonomous sales system, and that is a stated goal. What exists today, and what you should plan around, is a hybrid model - the agent handles most enquiries on its own and hands over to a human exactly at the points defined in advance. Managing the first 90 days properly is what moves that boundary forward, one question at a time.

Frequently asked questions

How long does it take before an AI agent is genuinely well tuned?

In practice most of the meaningful tuning happens in the first four to six weeks, because only by then have enough real enquiries accumulated to show patterns rather than isolated cases. The first week produces mainly wording fixes: a sentence that reads oddly, a question asked too early, a greeting that does not match the character of the business. Weeks two and three produce the genuinely valuable fixes, because that is when you discover what customers ask that you never thought of. From roughly week five the rate of change drops sharply and maintenance becomes a short routine. The pace depends on volume: a business receiving two hundred enquiries a month reaches stability much faster than one receiving twenty, simply because there is more to learn from.

What is the difference between a fault and a change, and why does it matter to me?

A fault is something that was configured and is not working: the agent does not reply, an enquiry was not saved as a record, the calendar does not sync a booked appointment, a file is not sent. Fixing faults is free and unlimited on every plan, because it is simply the product you are already paying for. A change is your request to alter the agent's behaviour: swap a price list or opening hours, reword an answer, add a document to the knowledge base, change a question the agent asks, or change an existing follow-up rule. Changes count against the monthly quota, which is set by plan. The distinction matters to you because it defines exactly what is inside the quota and what is not, and it prevents the familiar argument in which the client calls every request a fault and the vendor calls every request billable work.

Our customers send voice messages and photos. Does that inflate the message quota?

No. One message is counted as one agent reply, regardless of what kind of message the customer sent. A reply to a voice message, to a photo of a document or to a file counts exactly the same as a reply to plain text. There is no media multiplier and no double counting. It is also worth remembering that two further things are never counted: the customer's own incoming messages, and the number of times your automations and follow-ups run, because we have no trigger meters. What does increase consumption is the number of conversations and their length, so if consumption jumps it is worth checking whether the agent is answering in several short messages instead of one complete reply. That is a simple wording fix that lowers consumption without hurting the experience.

Can we change things in the system ourselves without contacting you?

Yes, and we recommend it. Everything you configure yourself in the interface is outside the change quota and unlimited: automations, follow-up rules, fields in the enquiries table, tables and views, statuses and kanban stages. The number of times those automations run is also neither metered nor billed. What does require a request to us is a change in the agent's own behaviour, meaning the conversation script or the knowledge base, and that is what counts as a change. The practical boundary is simple: what happens around the conversation is yours and fully open, and what happens inside the conversation goes through us, so that two parties never edit the same script without knowing about each other.

How do we know when it is time to move up a plan?

There are three clear triggers and one misleading one. The first is the channel: if customers insist on writing over WhatsApp and you are on Start, the plan no longer fits, because WhatsApp and calendar booking begin at Standard. The second is capability: in-chat payments, Instagram and Facebook, a team with separate permissions, several calendars, or an API and webhook connection all sit in Business. The third is simple arithmetic: if you pay overage every month, compare that overage against the included per-message price on the next plan, which falls as the plan rises. The misleading trigger is the number of changes, because if everything else fits and only the quota is short, extended support is considerably cheaper than moving up a plan. All prices exclude VAT.