Artisan AI implementation: why the sales agent does not reach the deal
An autonomous sales agent looks convincing in a demo: a lead writes — a response arrives in seconds, questions are closed, a meeting is on the calendar. In the working environment, everything breaks at the joints.
Artisan AI implementation begins not with setting up replies, but with a map of the request journey: where it lives, who picks it up, and at what moment the dialogue stops moving.
The first failure point is non-working hours. At night and on weekends, the agent either stays silent or falls into a template stub, and a lead who wrote at 23:40 has already received answers from two competitors by morning.
Automation of b2b sales without round-the-clock request intake simply shifts the loss to the hottest time — the one when the client is choosing between vendors.
The second is handoff to a manager. The agent collects parameters and “hands off” the lead to CRM, but the person sees the task an hour later, returns to the correspondence, where there are already three threads in different channels, and loses context.
Loss of requests in correspondence happens not at the moment of the question, but precisely at handoff: no single thread of dialogue — no continuation of the conversation.
The third is manual qualification. While budget, role in the deal, and timeline are determined by a human, the flow of requests hits their capacity, and the sales agent does not respond to the lead in those minutes when the decision has not yet been made.
Qualification should be handled by the agent — from the correspondence itself, giving the manager a ready profile with a history of touches.
Add the gap between channels: email, messenger, website form, and call live separately, and the same lead is created twice or not created at all. We break down how this is closed.
What implementation gives: effects in measurable indicators
The effect of the AI employee Artisan AI Ava SDR is measured not by ease of setup, but by four indicators visible in the deal tracking system: first response time, share of dialogues brought to qualification without a manager, handling of requests outside working hours, and load on the sales department.
Previously, the first response went out after hours, and a nighttime request waited until morning — by that time the client was already talking to a competitor.
Ava SDR responds within minutes, around the clock, asks qualifying questions, and passes the manager ready deal context.
| Indicator | Before implementation | After implementation |
|---|---|---|
| First response time | hours during working hours, at night — until morning | minutes, including night and weekends |
| Lead qualification | manually, after a manager's call | in dialogue, without manager involvement |
| Requests outside working hours | accumulated in queue until shift | processed immediately, meeting on calendar |
| Load on sales department | shift spent on initial triage | manager handles only qualified dialogues |
The manager stops being a filter for first-touch: more requests pass through per shift with the same team, and time goes to dialogues with a high probability of a deal.
We take measurements before and after using the same fields, so it is clear where there is an effect and where the scenario needs tuning.
Options for launching a sales agent: cloud, own environment, hybrid
The launch mode determines not only speed, but also where correspondence, deal history, and exports from the deal tracking system physically reside.
The agent reads incoming messages, deal history, and contact fields, and writes the result back — meaning during operation it sees the same data as the manager. Hence three schemes that are actually chosen between.
| Option | When suitable | Limitations |
|---|---|---|
| Cloud launch of the agent | A working environment is needed in a short time, correspondence is business-related, and there are no strict requirements for its placement | Processing takes place on the service side; separate coordination with security cannot be avoided |
| Closed environment and client data | Security or regulator requirements prohibit taking correspondence outside the perimeter | Deployment takes longer; updates and resources are on the customer's side |
| Hybrid integration scheme | Correspondence remains inside, while agent logic and model operate outside | It is necessary to design the exchange and ensure that only permitted fields go outside |
The choice almost always comes down to one thing: whether correspondence is allowed to leave your perimeter. If yes — the cloud provides the fastest start; if no — we calculate a hybrid, which covers most requirements without full deployment.
Connection to the deal tracking system is designed separately in each mode: in some cases it is standard exchange via an access key, in others — an intermediate layer inside the perimeter.
Project stages: from correspondence audit to live leads
The project proceeds in short iterations, and each stage ends with a verifiable artifact: analysis of dialogues, scenario scheme, working connection with the tracking system.
The order is structured so that errors in logic surface on correspondence the agent is not yet handling, rather than on live clients.
- Audit of sales department correspondence. We analyze dialogue history and the funnel: first response speed, share of requests without a response, typical objections, and places where deals get stuck.
- Design of agent logic. Qualification scenarios, rules for escalation to a manager, tone of response, and the list of what the agent has no right to promise the client.
- Setup of connections with the tracking system. Deals, statuses, owners, and exchange fields are configured in both directions — the agent's activity is visible in the card, and a status change alters its behavior.
- Test launch on real dialogues. We run the agent on historical requests and compare with how a strong manager would have responded; we count correct qualifications and escalations.
- Handoff and team training. Escalation regulations, access to settings, review of disputed dialogues, and rules for editing scenarios by your team.
- Acceptance of the sales agent. Measurement on a control sample: share of requests with a response, first response time, qualification quality, and tone preservation.
After acceptance, the agent works on the full flow, and we remain on scenario support and deviation analysis.
Handoff package: configurations, access policies, regulations
Handoff is not an export of settings, but a set of artifacts with which your team works without us: editing scenarios, changing escalation conditions, reviewing disputed dialogues. Below is what exactly remains with the customer after launching a sales agent based on Artisan AI.
- Configured scenarios and response rules: opening replies, qualifying questions, handling typical objections, stop words, and prohibited wording — tied to segments and incoming sources.
- Scheme of the agent's connections with your systems: where it writes the dialogue result, which card fields it updates, what it does when an external service is unavailable — indicating the person responsible for each connection.
- Access policies for correspondence: roles of managers and executives, who can see the entire thread, who has the right to edit scenarios, how rights are granted and revoked when an employee changes.
- Dialogue escalation regulations: conditions for handoff to a human (request for individual terms, legal question, negativity, several failed attempts), to whom the dialogue goes, within what time, and what context the agent attaches.
- Agent action log: every message, decision made, call to external systems, and triggered rule — with a timestamp and dialogue identifier, with export for audit and quality review.
- Sales agent documentation: instructions for managers — how to read dialogue history, where to intervene, how to restart a scenario; change map with rule versions and responsible person.
- Procedure for making changes: test environment, running edits on historical dialogues, and criteria for rollback to the previous scenario version.
Case: sales department of 12 people and three request channels
Before launch
Twelve managers handled three incoming channels: email, website form, and messengers. At night, on weekends, and on holidays the queue grew — by morning some requests were no longer relevant, and clients went to those who responded first. This was handled on a residual basis: hot deals first, then everything accumulated overnight.
After launch
The digital employee Ava SDR was connected to all three channels at once — a single queue, shared escalation rules, one history for each contact.
It handles nighttime and weekend requests itself: clarifies the task, checks against the catalog and price list, answers typical questions, and passes to a manager only those dialogues where a human is needed — non-standard terms, large volume, conflict.
First response time decreased to 40 seconds at any time of day. The share of dialogues closed without a manager reached 58% — these are requests about composition, delivery times, compatibility, and repeat inquiries.
Missed requests remained around 2% versus 17% before launch: the night shift stopped being the department's bottleneck.
Repeat client requests increased: it is easier to return when a response comes immediately and all correspondence is in one window. Managers switched to deals requiring negotiation and terms, instead of forwarding the price list and clarifying basic questions.
How a sales agent differs from a chatbot and auto-responder
A chatbot and auto-responder follow a pre-written tree: buttons, branches, prepared phrases. As soon as the client formulates a question in their own words, the dialogue hits “I didn't understand, choose a menu item” — and some requests are lost.
A sales agent holds the goal of the conversation, not the sequence of steps. It parses the meaning of the reply and chooses the next move itself: clarify the task, handle an objection, bring the conversation back to business. The response is built from the context of the correspondence, not from a button number.
The main difference, however, is dialogue memory with the client. The agent maintains a card: what was discussed, which roles and timelines were mentioned, which objections arose, in which channel the correspondence took place. Returning to the conversation a few days later starts not from zero, but from the last point.
Lead qualification in correspondence is structured just as substantively.
Instead of “leave your phone number, a manager will contact you,” the agent determines the task, scale, participants, and timeline, records the answers, and by formal criteria decides whether the client is ready to talk to a human.
Handoff of the dialogue to a manager is a conscious event, not a reset at the word “operator.” The manager receives a summary and transcript: what the client came with, what has already been promised, what remains to be clarified.
It is this logic that distinguishes the agent from an auto-responder, and it is also the basis of Artisan AI.
Doubts before launch: answering frequently asked questions
Before starting, technical teams ask almost the same five questions — they concern compatibility with already working processes, not trust in the technology.
Below we answer without marketing: what to do with a configured auto-responder, how non-standard wording is handled, and where our area of responsibility ends.
We already have an auto-responder running — will there be a conflict?
First we analyze the current rules and channels. Duplicate scenarios are disabled; we keep the email auto-reply as a stub during unavailability.
We build routing on the principle of “one incoming channel — one response source,” so the client does not receive two different emails for one request.
What happens with non-standard client questions?
Each scenario has a confidence threshold. Anything below it goes to a human along with the correspondence history, rather than being rewritten at random.
We configure the threshold separately by request types: lower for typical ones, higher for commercial terms, so the share of false answers stays within agreed boundaries.
How secure is correspondence with clients?
We grant access by roles, every action enters the log, and the transmission channel is encrypted. Correspondence is stored in your environment, its content is not used to train external services, and it is exported on request in machine-readable form.
Who is responsible for answer quality?
We are responsible for the correctness of scenarios, the logic of clarifying questions, integrations, and the quality metric.
Content — delivery terms, timelines, discounts — is the customer's area: we agree on a regulation by which the knowledge base is updated, and changes are checked before publication.
What if the knowledge base has an error in delivery terms?
The base is versioned; the previous revision is kept for rollback.
If an answer diverges from the current price list or terms, the scenario does not answer but transfers the dialogue to a manager with a note about the reason — this is cheaper than dealing with the consequences of an incorrect number in an invoice.
Let's discuss the task: where the pilot begins
A pilot of a sales agent based on Artisan AI begins not with setting up scenarios, but with an inventory: if it is unclear where leads come from, which fields are mandatory, and who accepts the agent's answer, automation turns into forwarding emails between a robot and a manager.
- Access: mailbox or domain for outbound, contact export, right to read correspondence for the selected segment.
- Offer: 2–3 segments handled by the agent, and typical objections with ready answers.
- Qualification criteria: when a lead is considered targeted and at what moment the dialogue goes to a human.
- Boundaries of autonomy: what the agent sends itself, and what requires manager confirmation.
- Point for receiving answers: CRM, email, or spreadsheet — and who processes them the same day.
- Pilot metrics: share of responses, transition into dialogue, number of leads passed to a manager.
At the first step, we deploy a test environment, launch the agent on one channel — for example, outbound email for one segment — and assemble scenarios with escalation rules.
A narrow slice provides an estimate of the scope of work without rewriting the processes of the entire team: it is clear how many dialogues the agent handles itself and where it breaks.
Next — a work plan for sales automation: second channel, integrations, lead handoff regulations, metric review after the pilot. Describe the task — we will return with an estimate and work plan.
