How a salon chain automated 74% of routine inquiries—and what to test in a pilot

The short version

In January 2026, Replify described deploying its HeyLibby virtual receptionist at the Seattle Sun Tan and Desert Sun salon groups. The vendor’s case page says the system handled about 74% of routine business inquiries—questions about opening hours and treatments—without escalation to staff. The same page gives a more precise 74.4%, with 85.5% for hours questions and 61.9% for treatment questions.

This is not an independent audit or a promise that another company will get the same result. An independent Agenccy.AI case card checked that the figures appear in the vendor’s publication, while explicitly noting that it found no independent confirmation of performance. The useful takeaway for a small business is not “AI will answer three quarters of our calls.” It is “separate repeatable information requests from situations that need an accountable employee, then measure the result on our own inquiries.”

What the case actually describes

Seattle Sun Tan and Desert Sun are two regional salon groups in Washington State. Replify’s publication says the group operates more than 60 locations. Repeated questions, inquiries after closing, and calls that pulled staff away from customers on site are described as the original problem.

The vendor says HeyLibby answered routine questions around the clock and assisted with schedules, services, and basic location information. The case does not disclose the exact telephony integration, model, price, volume of reviewed inquiries, or method used to count errors. Those details therefore cannot be treated as established facts or copied into another project as if they were known.

The denominator matters: 74.4% refers to “business inquiries,” defined in the case as questions about hours and treatments. It is not the share of all calls, a sales conversion rate, or a resolution rate for difficult complaints. The same page also uses the rounded figure 74%, plus separate 85.5% and 61.9% figures for the two categories. A useful analysis preserves those distinctions rather than turning them into a louder promise.

Why this scenario may fit a smaller business

A salon, repair shop, studio, pickup point, or small local chain may receive the same few questions every day:

• when a particular location is open and how holiday hours change;
• which services or products are available and what they cost;
• how to book, reschedule, or check an order;
• where to send a question that requires an employee.

Repetition and a verifiable source of truth make this kind of task a reasonable pilot candidate. The first release does not need to give a model authority to decide refunds, promise a custom discount, change an order, or handle a dispute. It can simply answer a limited set of questions quickly and consistently, then hand the rest to a person.

If a business has one location and receives only a few such calls a day, a separate voice-AI system may be more complicated and expensive than updating an IVR, a public FAQ, or a callback schedule. The size of a chain is not, by itself, a reason to buy AI. The calculation should account for the cost of missed inquiries and staff time spent on repetitive answers.

How to adapt the approach without copying the percentage

1. Measure the flow and classify inquiries first

Take an anonymized sample of calls or messages from two to four weeks. Do not upload recordings containing personal data to a new service until access, storage, and processing arrangements have been reviewed. The first pass only needs to classify the topic and outcome: answered, booked, transferred, missed, or unresolved.

Split inquiries into at least four groups:

• information whose answer already exists in an approved source;
• an operation requiring current data from a CRM, calendar, or order system;
• an exception, dispute, complaint, or financial decision;
• an unclear topic that cannot be classified reliably.

The first group is usually the safest place to start. The second requires integration and data-validation rules. The last two need a clear handoff to an employee.

2. Prepare a source of truth

Bring current opening hours, addresses, services, prices, booking terms, and contact details into one managed data set. For a multi-location business, use a directory with a location identifier and a last-updated date—not several similar spreadsheets in separate folders.

Assign an owner for the data. Specify who changes the schedule, who checks the update, and how quickly a new price must appear in answers. If the schedule is stale, a model will only spread a stale answer faster.

The deployment requirements differ between a local model, RAG, and a cloud service, but the source of business facts is the same: the model must not guess a price or availability. It should answer from approved data and hand off when information is missing.

3. Restrict what the agent can do

At first, the system can provide information and, if verified, offer available appointment slots. It should not independently change prices, cancel payments, promise compensation, or decide complaints.

Agree on handoff conditions: a customer request, low confidence, conflicting sources, a sensitive question, or an unusual request. Give the employee a short summary of the topic and information already collected so the customer does not have to repeat everything.

4. Test quality on real examples before launch

Build a test set of typical and awkward questions: alternate names for the same service, colloquial wording, background noise, interruptions, holiday hours, a question covering several locations, and a request not represented in the knowledge base. Define the expected answer—or the requirement to transfer to a human—before running each test.

Automate checks for facts and format wherever the answer is unambiguous. Separately review several difficult and borderline cases. Measure more than the share of inquiries answered without an operator:

• correctness of hours, prices, and terms;
• transfer rate and failed-transfer rate;
• repeat contacts about the same issue;
• abandoned calls and waiting time;
• complaints, corrections, and customer satisfaction;
• cost per inquiry that was actually resolved.

“Answered without a person” does not mean “resolved.” Sometimes a transfer is the right outcome, not an automation failure.

A model pilot-economics calculation

The following is an illustrative calculation, not a figure from the Replify case. Assume a business receives 1,000 information inquiries per month; the system genuinely resolves 35% of them; an employee used to spend an average of three minutes on each; and the company’s fully loaded staff-hour cost is assumed to be RUB 600.

Under these assumptions, the system frees about 17.5 hours a month: 1,000 × 35% × 3 minutes ÷ 60. The modelled value is RUB 10,500. If the monthly license, telephony, integration, quality control, and support cost more than that, direct labor-time savings do not cover the expense. Any additional value—fewer leads lost after closing, faster booking, or fewer repeat calls—should be measured separately. Do not substitute promised revenue for attribution evidence.

A pilot spreadsheet can start with four columns: baseline inquiry volume, share of suitable questions, actual share successfully resolved without help, and monthly service cost. Change one assumption at a time and calculate a range rather than a single precise payback figure.

A practical one-month plan

• Week 1: collect inquiry statistics and choose one or two simple scenarios.
• Week 2: consolidate the information source, assign an owner, and define update rules.
• Week 3: test on representative examples and run in suggestion mode for staff.
• Week 4: enable a limited share of traffic or one location, keep a fast human handoff, and review errors daily.

Record baseline values before starting: inquiry volume, missed calls, average response time, repeat contacts, and cost. After launch, compare the same definitions over a comparable period. Otherwise, percentages may look impressive without showing whether customers or the business are better off.

Limitations and takeaway

The published 74.4% applies to a narrow category of questions and comes from the solution vendor; the available materials contain no independent validation of the result. The customer is named, but the model, price, architecture, and measurement methodology are not disclosed. The case is a useful source of questions to ask, not proof of future savings for your business.

Start with a process where the answer is short, the data source is controlled, an error is easy to detect, and handing off to a person is straightforward. A sensible small-business pilot is not “automate service”; it is “test one repeatable inquiry flow on a limited volume, with stop criteria agreed in advance.”

**What the manager should take away:** ask the team for one month of inquiry data and identify two categories whose answers are already unambiguous in the current schedule or price list.