AI system for automatic follow-up after a client inquiry

Why follow-up AI loses inquiries on long chains

The bottleneck of follow-up AI is almost never the quality of text generation. It is in the processing queue: inquiries arrive unevenly, but are handled in a single stream, and the queue grows faster than it can be cleared.

Then simple arithmetic kicks in — the delay of the first response accumulates across the entire chain, not just at the entry point.

While processing is synchronous, each inquiry waits for the previous one. At peak — a morning flow of requests or a wave after a mailing — response time goes from minutes to hours.

During that time, the person writes elsewhere or cools down, and automatic follow-up starts into a dialog that effectively no longer exists: inquiries that were warm at the entry are lost without a second touch.

The second cause of losses is unprocessed dialog state. If a chain step and the timer for the next touch live in the process memory, any restart, rollout, or timeout resets progress: the client receives either nothing or the first message again.

A resilient scheme stores step state and touch history in external storage, and makes step retry idempotent — a failure does not turn into a duplicate.

Separately, retries without differentiation hurt: a retry sends the same touch a second time, and instead of continuing the conversation, the person receives a duplicate and unsubscribes. This is treated by deduplication by inquiry key and explicit rules on the number of attempts.

The chain breaks not on text generation, but on orchestration: queue, first response delay, step state, and retries. We break down how this is closed.

What changes after automating touches: measurable effects

The effect of touch automation is visible not in a single metric, but in a set of metrics that we take before and after implementation. Below are those that show that the logic of automatic touches really works, and does not simply respond with a template.

Channels such as WhatsApp are connected to the same events as the CRM, so the metric is calculated across all points of contact.

• Time to first touch. Before automation — from tens of minutes to several hours: the request waits for an available employee. After — 15–60 seconds from the event in the system, regardless of shift and time zone.
• Share of automatic touches. The initial response, clarifying questions, and reminders are sent without a human — 70–90% of touches in the first dialog cycle.
• Share of inquiries without manual labor. The operator did not get involved at all — 30–50% on typical requests, the rest reach a human already with collected context.
• Eliminated class of dialog breaks. The client's response is no longer lost between shifts, when an employee leaves, or when a channel fails: every incoming message raises a task and the timer for the next step.
• Load predictability. Touches follow rules, not whoever got to them: peaks are spread out, evening inquiries do not cool down until morning.

We take metrics on the pilot: control group versus flow with automatic touches — this way the effect is separated from seasonality. The output is a dashboard where the current state of processing and the logic step that needs fine-tuning are visible.

Modes of automatic touches: comparison of approaches

The mode of touches is chosen not by ease of setup, but by the cost of error in a specific step of the scenario.

Where the wrong tone or an outdated fact in a message costs more than delay, the operator remains in the loop; where the speed of the first response decides, automation wins over any shift. Below are three modes that are realistically chosen between when assembling omnichannel chains.

Each has its own limitations: speed, coverage completeness, amount of manual work, and predictability under growth in the flow of inquiries.

In practice, a chain is almost always assembled from different modes by segments — by inquiry type, channel, and completeness of customer data.

The mode is set separately for each step — first response, reminder, return to dialog after a pause — and changed by a rule, without rewriting the entire chain.

Before launch, we run it on historical inquiries: we look at what share of touches went without operator editing and how many dialogs returned to conversation.

Implementing follow-up AI: stages of engineering work

The order of work is structured so that every decision relies on confirmed data, not assumptions.

First we break down how inquiries are processed now and where exactly contact is lost, then we assemble scenarios and test them on real conversation history — before the system starts writing to clients.

This order removes the main risk: automation that formally works but responds in the wrong tone and at the wrong moment.

1. Communication audit. We export inquiry history by channel, label request types, time to first response, and the share of dialogs that break off without a response. The output is a map: which inquiries can be closed automatically, which must go to an operator.

2. Scenario design. We agree on touch logic: triggers, intervals, message tone, frequency limits, and stop rules. Separately, we describe escalation — the conditions under which the system passes the dialog to a human with full conversation context.

3. Setup of scenarios and integrations. We connect data sources and channels, configure response templates and variables for a specific request. At this step, we fix what data the system sees about the client and what it does not.

4. Testing on historical data. We run the finished logic on past inquiries in shadow mode: the system generates responses but does not send them. We look at where triggers are unnecessary, where responses are inaccurate, and correct scenarios before launch.

5. Pilot on a limited flow. We enable automatic touches for part of the inquiries, compare with the control group by response time and share of returned dialogs.

6. Handover to operation. We hand over regulations, access, instructions for editing scenarios, and a monitoring panel. The customer's team can change texts and logic without us — edits in the interface, not in code.

What we hand over: configurations, schemas, regulations

We hand over not a "working service," but a system that your team can maintain and change without us.

The behavior of follow-up AI — scenarios, connections between services, escalation thresholds — is described in configuration, not in code and not in the developer's head.

• Scenario configurations — follow-up branches by inquiry type, channel, and deal stage: delays between touches, chain stop conditions, message templates, and variables from the customer card.
• Integration schema — a map of connections between CRM, channels, and the decision-making module: which fields are read and written, where failure points are, how redelivery is handled when an external service is unavailable.
• Escalation rules — to whom and when the dialog goes: dissatisfaction in tone, silence after several touches, a discount request or legal question is passed to an employee together with collected context.
• Set of pre-rollout checks — scenario tests on typical and edge-case inquiries, a run on historical dialogs, control of duplicates and delays.
• Support regulations — what is visible in monitoring, which deviations require intervention, who edits the configuration and within what timeframe, how an unsuccessful change is rolled back.
• Documentation — description of the data schema, decision log on scenario logic, walkthrough with your team, and a support period after launch.

We check each item at acceptance together with your engineer: until you reproduce the scenario and make a change with your own hands, the work is not considered delivered.

Case: touches in the sales department — metrics before and after

Sales department of a service company: nine managers and 300–400 inbound inquiries per month from forms, messengers, and email. Requests were collected in amoCRM, and each manager kept the sequence of touches in their head in their own way.

Measurements before implementation: median first touch 4 hours 20 minutes, share of inquiries with a fully completed chain 34%, 6–8 manual actions per operator per hour.

The cause was not people: half of the requests came in the evening and on weekends, reminders lived in personal notes.

By the time they returned to the dialog, the client was often already choosing another supplier, and the deal context had to be restored by reading the entire conversation.

What was changed

The model parses the inquiry text, deal history, and channel, determines the request type, and assembles a chain of touches for it: confirmation, clarifying question, sending terms, follow-up call, return of a cooled-down client.

A task with a draft response and deadline appears for the manager on its own; overdue goes to the manager. The manager edits the wording, but no longer remembers the steps — the system is responsible for the chain.

What changed in numbers

Median first touch — 3 minutes, share of inquiries with a full chain — 91%, manual actions per operator — 2–3 per hour instead of 6–8. The operator handles twice as many dialogs without overtime: routine went to automation, conversations and deal decisions remained.

The result is sustained not by enthusiasm: each step has a mark in the card, you can see where the chain breaks and at which touch the client responds. This also provides material for editing scenarios — chains are refined based on actual responses, not assumptions.

What to do if your own email system is already deployed?

If you already have your own email system running, there is no need to replace it. The AI layer is installed as an add-on on top of the current environment and connects to the same mailboxes, channels, and accounting system that employees use. Conversations remain where they are now: there is no need to migrate history or retrain the team.

Integration with the existing system is built on events. The add-on receives a notification about a new inquiry or response, pulls in the context of the conversation and previous touches, and responds on behalf of the same address. For the client, this is one continuous communication, not a second communication channel.

Channel compatibility is checked before start: if the system provides events and allows sending on behalf of the user, the channel connects directly.

Where such capability is not available, an intermediate layer is installed — the model prepares the text, and the operator sends it in the familiar interface.

Implementation proceeds gradually. First, shadow mode: the system only suggests drafts and does not respond on its own. At this stage, metrics are taken — the share of responses accepted without edits and the time to first touch of the client.

Then auto-responses are enabled for a narrow class of inquiries: receipt confirmation, request for missing data, request status. After that, the share grows by metrics, not by feelings.

Rollback is turning off the rule: the channel continues to work as before, history remains in the source system.

Technical doubts before starting work

Before launch, engineering teams ask the same questions: how the system distinguishes a real client response from an auto-reply, where data lives, and what happens during a failure. Below are answers without marketing, in the form in which we give them at a technical review.

Is recognition quality sufficient on short responses?

Phrases like "call back later" or "no longer relevant" are parsed by intent, not by individual words: the context of the entire conversation and previous touches is taken into account.

We check accuracy on the customer's dialog history before launch, and put disputed categories out for labeling. Where the model is not confident, the dialog is passed to an operator rather than closed automatically.

How is customer data protected?

Conversations and touch history are stored in your environment or in a dedicated environment with encryption and role separation. Access is available only to service accounts and operators with the required role; all actions are logged.

Personal data can be excluded from training samples, and only the fields without which a touch cannot be built go to external services.

What happens if the service goes down mid-chain?

Each touch is stored with a state: sent, waiting, requires retry — the queue survives a restart. After recovery, undelivered steps go out on schedule, and duplicates are cut off by inquiry identifier, so the client will not receive two identical emails. Missed steps are either caught up or closed by a rule defined in advance.

Let's discuss the task: where a project begins

Project estimation for follow-up relies on your data, not average market numbers: we need to see how many inquiries arrive, through which channels, and at which step contact is lost.

Therefore, the start is a short exchange of inputs, after which we return with a work plan and timeline estimate.

What you send and what you get in response:

• Composition of source data. An export of inquiries for a period, fields and statuses in the CRM, a list of channels — from them it is clear how many touches are actually needed and where contact is currently lost.
• Touch logic. The reason for follow-up, the interval after the inquiry, the tone of messages, and the behavior rule when the client is silent.
• Integration points. Which system remains the source of truth and in what form it provides events about a new inquiry and about a response.
• Success criteria. Share of respondents, time to first touch, share brought to deal — by these metrics we calculate the pilot result.
• Work plan. Stages, responsible parties on both sides, and the points where your approval of scenarios and wording is required.
• Pilot launch. A limited flow of inquiries and an observation period, after which we decide on scaling.

We return with the project estimate and work plan after reviewing these inputs — with an explicit indication of what we close in the pilot and what we move to the next stage.