Как сервисному бизнесу автоматизировать проверку качества обслуживания клиентов

Средний

11 мин

627

Туториал

Пока впечатление о полученной услуге свежее, клиент лучше помнит детали и охотнее делится обратной связью. Бизнесу это помогает быстрее находить слабые места в сервисе и исправлять их.

Когда клиентов мало, администратор может быстро их обзвонить: спросить, всё ли понравилось, и зафиксировать ответы. При масштабировании бизнеса этот вариант уже не подходит: звонки отнимают много времени. В итоге часть визитов остаётся без проверки, а бизнес узнаёт о проблеме, когда недовольный клиент опубликовал негативный отзыв в интернете, ухудшив рейтинг компании, и перестал возвращаться.

В этой статье разберём, как автоматизировать исходящие звонки. Клиенту, получившему услугу, звонит голосовой робот и проводит короткое анкетирование. Результаты опроса сразу попадают в рабочую таблицу, а если клиент остался недоволен, управляющий дополнительно получает СМС и может быстрее разобраться в ситуации.

Стек решения: Python 3.10+, Flask, requests, python-dotenv, SQLite, YCLIENTS API, голосовой робот и SMS API МТС Exolve, MWS Tables.

Общая схема работы

Сценарий начинается, когда YCLIENTS считает визит завершённым. Сервис получает вебхук, забирает полную карточку посещения и проверяет, что по этому визиту ещё не было звонка.

После этого он создаёт локальную запись состояния и запускает голосового робота, который звонит клиенту и задаёт три вопроса: как он оценивает услугу, цену и готов ли вернуться. Такой набор вопросов сохраняет звонок коротким и даёт бизнесу оценку качества работы, восприятие стоимости и риск потери клиента.

После каждого ответа сервис получает колбэк, сохраняет шаг опроса и обновляет статус визита в локальной базе. Если клиент не ответил или звонок завершился с ошибкой, это тоже фиксируется отдельным статусом.

Если оценка услуги низкая, владельцу отправляется СМС, а результат записывается в таблицу. После этого по каждому визиту видно, дошёл ли клиент до конца опроса и какая была обратная связь.

Архитектура решения

Всё работает на одном Flask-сервисе, трёх внешних системах и локальной базе.

YCLIENTS хранит основные данные визита и присылает событие о его завершении. SQLite хранит текущее состояние опроса: статус, идентификатор звонка, ответы по шагам и отметку об отправке алерта. MWS Tables получают уже итог по визиту, когда опрос завершён.

App.py управляет статусами визита: принимает вебхуки, связывает их с нужной записью и запускает внешние вызовы. Основной ключ сценария — visit_id. Идентификатор звонка нужен, чтобы потом привязать колбэк голосового сценария к уже созданной записи.

Внешние вызовы вынесены в отдельные файлы: yclients_api.py читает визит из YCLIENTS, exolve_voice.py запускает звонок, sms_alerts.py отправляет СМС, tables_api.py пишет итог в таблицу.

Пререквизит

Нужен Python 3.10+: в коде используется синтаксис str | None. Токены, идентификатор таблицы и порог низкой оценки лежат в .env.

python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

Пример переменных окружения:

WEBHOOK_SECRET=change-me
YCLIENTS_BASE_URL=https://api.yclients.com/api/v1
YCLIENTS_PARTNER_TOKEN=***
YCLIENTS_USER_TOKEN=***
MWS_TABLES_BASE_URL=https://tables.mws.ru
MWS_TABLES_API_KEY=***
MWS_TABLE_ID=***
MWS_VIEW_ID=***
EXOLVE_API_KEY=***
EXOLVE_CAMPAIGN_ID=***
EXOLVE_CAMPAIGN_URL=https://api.exolve.ru/campaign/v1/Call
EXOLVE_SENDER=SalonBot
OWNER_ALERT_PHONE=79990001122
LOW_SCORE_THRESHOLD=2
DB_NAME=salon_quality.db

Для финальной записи результатов в MWS Tables заранее создайте таблицу quality_results_table со следующими колонками:

visit_id — строка
client_name — строка
master_name — строка
branch_name — строка
visit_at — дата/время
service_score — число
price_score — число
return_intent — число
survey_status — строка
alert_sent — логическое поле

В текущем коде секрет вебхука передаётся как параметр запроса token, поэтому сам URL вебхука тоже нельзя светить. Ключи API приложение читает через python-dotenv.

Шаг 1. Поднимаем конфиг и локальное состояние

Опрос не заканчивается одним событием, поэтому сервису нужна отдельная запись по каждому визиту. Состояние опроса сервис держит в Config и таблице surveys. В ней лежат контекст визита и технические поля опроса: status, call_id, три оценки и alert_sent. Первичный ключ на visit_id защищает от дублей.

# config.py

from dotenv import load_dotenv
import os


load_dotenv()


class Config:
   WEBHOOK_SECRET = os.environ.get("WEBHOOK_SECRET", "super-secret-token")


   YCLIENTS_BASE_URL = os.environ.get("YCLIENTS_BASE_URL", "https://api.yclients.com/api/v1")
   YCLIENTS_PARTNER_TOKEN = os.environ.get("YCLIENTS_PARTNER_TOKEN", "***")
   YCLIENTS_USER_TOKEN = os.environ.get("YCLIENTS_USER_TOKEN", "***")


   MWS_TABLES_BASE_URL = os.environ.get("MWS_TABLES_BASE_URL", "https://tables.mws.ru")
   MWS_TABLES_API_KEY = os.environ.get("MWS_TABLES_API_KEY", "***")
   MWS_TABLE_ID = os.environ.get("MWS_TABLE_ID", "***")
   MWS_VIEW_ID = os.environ.get("MWS_VIEW_ID", "***")


   EXOLVE_API_KEY = os.environ.get("EXOLVE_API_KEY", "your_exolve_key")
   EXOLVE_CAMPAIGN_ID = os.environ.get("EXOLVE_CAMPAIGN_ID", "***")
   EXOLVE_CAMPAIGN_URL = os.environ.get("EXOLVE_CAMPAIGN_URL", "https://api.exolve.ru/campaign/v1/Call")
   EXOLVE_SENDER = os.environ.get("EXOLVE_SENDER", "SalonBot")
   OWNER_ALERT_PHONE = os.environ.get("OWNER_ALERT_PHONE", "79990001122")


   LOW_SCORE_THRESHOLD = int(os.environ.get("LOW_SCORE_THRESHOLD", 2))
   DB_NAME = os.environ.get("DB_NAME", "salon_quality.db")

Ниже минимальная схема таблицы, в которой сервис хранит состояние опроса.

# database.py

def init_db():
   with get_conn() as conn:
       conn.execute("""
       CREATE TABLE IF NOT EXISTS surveys (
           visit_id TEXT PRIMARY KEY,
           client_name TEXT,
           client_phone TEXT,
           master_name TEXT,
           branch_name TEXT,
           visit_at TEXT,
           status TEXT NOT NULL,
           call_id TEXT,
           q1_service_score INTEGER,
           q2_price_score INTEGER,
           q3_return_intent INTEGER,
           alert_sent INTEGER NOT NULL DEFAULT 0,
           created_at INTEGER NOT NULL,
           updated_at INTEGER NOT NULL
       )
       """)
       conn.commit()

Эта таблица хранит текущее состояние опроса. Данные визита и технический статус сервис держит в одной записи, без отдельного журнала событий.

Сервис использует такие статусы:

NEW — визит создан локально, опрос еще не запущен
CALL_STARTED — звонок запущен
Q1_ANSWERED — получен ответ на первый вопрос
Q2_ANSWERED — на второй
Q3_ANSWERED — и на третий
COMPLETED — опрос завершен
NO_ANSWER — клиент не ответил
FAILED — опрос завершился технической ошибкой

Последовательность статусов при успешном звонке выглядит так:

NEW -> CALL_STARTED -> Q1_ANSWERED -> Q2_ANSWERED -> Q3_ANSWERED -> COMPLETED

Если клиент не ответил:

NEW -> CALL_STARTED -> NO_ANSWER

Если звонок завершился ошибкой:

NEW -> CALL_STARTED -> FAILED

Шаг 2. Принимаем закрытый визит из YCLIENTS

Вебхук YCLIENTS сообщает, что визит закрыт. Дальше сервис проверяет token, смотрит на attendance == 1 и отдельно забирает карточку визита через get_visit(). В локальную БД он пишет уже нормализованные данные.

Пример входящего вебхука:

{
 "id": "98765",
 "company_id": "12345",
 "attendance": 1
}

Ниже сам обработчик этого вебхука.

# app.py

@app.route("/webhook/yclients/visit", methods=["POST"])
def yclients_webhook():
   if request.args.get("token") != Config.WEBHOOK_SECRET:
       return "Forbidden", 403


   data = request.get_json(silent=True) or {}
   visit_id = str(data.get("id") or "")
   company_id = str(data.get("company_id") or "")


   if not visit_id or not company_id:
       return "Bad Request: visit_id or company_id missing", 400


   if data.get("attendance") != 1:
       return jsonify({"status": "ignored_status"}), 200


   visit_raw = get_visit(company_id, visit_id)
   visit = normalize_visit(visit_raw)


   if not visit["client_phone"]:
      return jsonify({"status": "invalid_phone"}), 200


   created = create_survey_if_new(visit)
   if not created:
      return jsonify({"status": "duplicate"}), 200

После первичной проверки сервис отдельно нормализует ответ YCLIENTS и дальше работает уже с одной и той же структурой визита.

# yclients_api.py

def normalize_phone(phone: str | None) -> str | None:
   if not phone:
       return None
   digits = "".join(ch for ch in str(phone) if ch.isdigit())
   if len(digits) == 11 and digits.startswith("8"):
       digits = "7" + digits[1:]
   return digits if len(digits) == 11 and digits.startswith("7") else None


def normalize_visit(visit: dict) -> dict:
   return {
       "visit_id": str(visit.get("id")),
       "client_name": visit.get("client", {}).get("name"),
       "client_phone": normalize_phone(visit.get("client", {}).get("phone")),
       "master_name": visit.get("staff", {}).get("name"),
       "branch_name": visit.get("company", {}).get("title"),
       "visit_at": visit.get("datetime")
   }

После нормализации в локальную базу попадает карточка визита с клиентом, мастером, филиалом и временем посещения. Повторный вебхук не создаёт дубль, потому что запись привязана к visit_id. Если телефон не проходит нормализацию, сервис возвращает invalid_phone. Завершённым визит считает только по attendance == 1.

Шаг 3. Запускаем голосовой опрос через МТС Exolve

Когда визит уже записан локально, сервис запускает по этому клиенту голосовую кампанию в МТС Exolve.

*Скриншот схемы голосового робота МТС Exolve*

В запрос уходит не только телефон, но и initialData.visit_id. Этот ключ нужен, чтобы потом связать колбэк с нужным визитом. В ответе от МТС Exolve сервис дополнительно сохраняет call_id как идентификатор звонка для обратного маршрута вебхука и переводит запись в статус CALL_STARTED.

# exolve_voice.py

def start_quality_campaign(phone: str, visit_id: str) -> dict:
   headers = {"Authorization": f"Bearer {Config.EXOLVE_API_KEY}", "Content-Type": "application/json"}
   payload = {
       "campaign_id": Config.EXOLVE_CAMPAIGN_ID,
       "params": {
           "destination": phone,
           "initialData": {"visit_id": visit_id}
       }
   }
   resp = requests.post(Config.EXOLVE_CAMPAIGN_URL, headers=headers, json=payload, timeout=20)
   resp.raise_for_status()
   return resp.json()

Дальше сервис сохраняет идентификатор звонка в SQLite и переводит визит в статус CALL_STARTED.

# app.py

response = start_quality_campaign(visit["client_phone"], visit["visit_id"])
call_id = response.get("call_id") or response.get("id")
update_survey_status(visit["visit_id"], "CALL_STARTED", call_id=call_id)
return jsonify({"status": "accepted"}), 200

На этом шаге сервис создаёт звонок и сохраняет два ключа: идентификатор визита и идентификатор звонка. Если вызов к МТС Exolve не проходит из-за сетевой ошибки или не пройденной авторизации, вебхук YCLIENTS не завершается штатно. Ограничение здесь прямое: вызов к МТС Exolve идёт синхронно внутри вебхука.

Шаг 4. Принимаем ответы DTMF и ведём состояние опроса

Во втором вебхуке сервис получает не итог опроса целиком, а отдельные шаги: вопрос, цифру ответа и статус звонка. q1_service_score хранит оценку услуги, q2_price_score — оценку цены, q3_return_intent — готовность вернуться. Отдельные ветки NO_ANSWER и FAILED нужны, чтобы отличать отсутствие ответа от технического сбоя.

Маршрут /webhook/exolve/survey снова проверяет token, приводит тело запроса к внутреннему контракту через normalize_callback, ищет опрос по call_id или visit_id, преобразует dtmf_digit в число и сохраняет ответ в одно из трёх полей состояния.

Пример колбэка, который отправляет голосовой сценарий:

{
 "visit_id": "98765",
 "call_id": "call_001",
 "current_step": "q2",
 "dtmf_digit": "4",
 "result_status": "COMPLETED"
}

Дальше сервис приводит такой колбэк к короткому внутреннему формату.

# exolve_voice.py

def normalize_callback(payload: dict) -> dict:
   return {
       "call_id": payload.get("call_id"),
       "visit_id": payload.get("visit_id"),
       "step": payload.get("current_step"),
       "digit": payload.get("dtmf_digit"),
       "result_status": payload.get("result_status")
   }

После нормализации у обработчика остаются пять полей: шаг, цифра, статус, visit_id и call_id.

# app.py

if cb.get("result_status") == "NO_ANSWER":
   update_survey_status(visit_id, "NO_ANSWER")
   return jsonify({"status": "processed"}), 200


if cb.get("result_status") == "FAILED":
   update_survey_status(visit_id, "FAILED")
   return jsonify({"status": "processed"}), 200 


if step == "q1":
   update_survey_status(visit_id, "Q1_ANSWERED", q1_service_score=digit)
   return jsonify({"status": "step_saved"}), 200




if step == "q2":
   update_survey_status(visit_id, "Q2_ANSWERED", q2_price_score=digit)
   return jsonify({"status": "step_saved"}), 200 


if step == "q3":
   update_survey_status(visit_id, "Q3_ANSWERED", q3_return_intent=digit)
   finalize_survey(visit_id)
   return jsonify({"status": "step_saved"}), 200

На этом шаге сервис либо сохраняет ответ, либо переводит опрос в терминальный статус. Прикладные ошибки здесь простые: 404, если визит не найден, и 400, если пришёл неверный шаг или цифра. Код проверяет только int, но не диапазон оценки.

Шаг 5. Финализируем опрос, отправляем СМС и пишем результат в таблицу

Когда опрос заканчивается, сервис читает запись из SQLite, при низкой оценке отправляет СМС владельцу и затем пишет итог по визиту в таблицу.

Функция finalize_survey читает запись из БД и сначала проверяет первую оценку. Если q1_service_score меньше или равен LOW_SCORE_THRESHOLD, сервис вызывает send_low_score_alert через SMS API МТС Exolve. Затем из локальной записи сервис собирает итог по визиту и отправляет его в таблицу.

# app.py

def finalize_survey(visit_id: str):
   survey = get_survey(visit_id)
   if not survey:
       return


   is_alert_sent = False


   if survey["q1_service_score"] is not None and survey["q1_service_score"] <= Config.LOW_SCORE_THRESHOLD:
   try:
       send_low_score_alert(
           survey["master_name"],
           survey["client_name"],
           survey["q1_service_score"]
       )
       is_alert_sent = True
   except Exception:
       is_alert_sent = False


   record = {
       "visit_id": survey["visit_id"],
       "client_name": survey["client_name"],
       "master_name": survey["master_name"],
       "branch_name": survey["branch_name"],
       "visit_at": survey["visit_at"],
       "service_score": survey["q1_service_score"],
       "price_score": survey["q2_price_score"],
       "return_intent": survey["q3_return_intent"],
       "survey_status": "COMPLETED",
       "alert_sent": is_alert_sent
   }

На этом месте app.py уже собрал финальный record. Дальше один клиент отправляет СМС владельцу, а второй пишет итог по визиту в таблицу.

# sms_alerts.py

headers = {"Authorization": f"Bearer {Config.EXOLVE_API_KEY}", "Content-Type": "application/json"}
payload = {"number": Config.EXOLVE_SENDER, "destination": Config.OWNER_ALERT_PHONE, "text": text}
resp = requests.post(url, headers=headers, json=payload, timeout=20)
resp.raise_for_status()

В таблицу уходит уже итог по визиту: оценки, статус опроса и отметка об алерте.

# tables_api.py

headers = {"Authorization": f"Bearer {Config.MWS_TABLES_API_KEY}", "Content-Type": "application/json"}
payload = {
   "records": [{"fields": record}],
   "fieldKey": "name",
}
resp = requests.post(url, params=params, headers=headers, json=payload, timeout=20)
resp.raise_for_status()

На этом шаге сервис отправляет СМС владельцу и пишет строку в таблицу. SQLite остаётся хранилищем состояния, а команда смотрит итог уже в Таблицах. Если любой вызов в этом блоке падает, визит переходит в FAILED. Общей транзакции между СМС, записью в таблицу и локальным статусом здесь нет.

Запуск и проверка

Чтобы прогнать сценарий целиком, понадобятся токены YCLIENTS, МТС Exolve и идентификаторы таблицы. После заполнения .env достаточно поднять Flask-приложение и либо закрыть тестовый визит в YCLIENTS, либо отправить вебхук вручную.

python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
flask --app app run --port 5000

Если проверяем первый маршрут вручную, отправляем запрос на вебхук YCLIENTS. При валидном секрете и корректных внешних токенах ожидаем {"status":"accepted"}.

curl -X POST "http://127.0.0.1:5000/webhook/yclients/visit?token=super-secret-token" \
 -H "Content-Type: application/json" \
 -d '{"id":"98765","company_id":"12345","attendance":1}'

Когда запись уже создана, колбэк от голосового сценария можно эмулировать отдельно. Для локальной проверки удобно отправлять visit_id без call_id, тогда маршрут ищет опрос напрямую по визиту. После первого вебхука в SQLite уже должна лежать строка со статусом CALL_STARTED и сохранённым call_id, если внешний вызов кампании отработал штатно.

curl -X POST "http://127.0.0.1:5000/webhook/exolve/survey?token=super-secret-token" \
 -H "Content-Type: application/json" \
 -d '{"visit_id":"98765","current_step":"q1","dtmf_digit":"2","result_status":"COMPLETED"}'

После колбэка с q1 строка должна перейти в Q1_ANSWERED и получить q1_service_score. После колбэка с q3 сервис либо завершит опрос статусом COMPLETED и создаст запись в таблице, либо пометит визит как FAILED, если финализация не прошла. Проверять в итоге нужно три точки: переходы status в SQLite, СМС на OWNER_ALERT_PHONE при низкой оценке и итоговую запись в таблице после третьего шага.

Если приходят 4xx, смотрим на token, company_id, visit_id и формат цифры. Если получаем 5xx, причина обычно в сетевой ошибке при вызове YCLIENTS, МТС Exolve или Таблиц.

В итоге

Такой сценарий помогает бизнесу быстро получать обратную связь о качестве сервиса и компания узнаёт о качестве обслуживания клиента практически сразу после оказания услуги. Это даёт возможность быстро решить проблему и не допустить ее повторения, а еще увеличивает шанс на повторный визит клиента, мнение которого услышали и учли.

Решение можно запустить за пару вечеров. Если эффект есть, сценарий можно расширять: встраивать в CRM, добавлять повторные касания, автоматизировать разбор негатива. Такой подход превращает работу с клиентами в постоянный процесс мониторинга и управления качеством сервисного обслуживания.

Возможности для развития

Добавить повторный контакт по клиентам, которые не ответили на первый звонок
Развести реакцию по уровню негатива: критические случаи отправлять сразу, остальные разбирать в течение дня
После низкой оценки не только слать СМС владельцу, но и ставить задачу на обратный звонок или разбор кейса
Смотреть результаты отдельно по филиалам, мастерам, услугам и времени визита
Сделать разные сценарии для новых и постоянных клиентов
Собрать регулярный отчёт по покрытию опроса, доле ответов, низким оценкам и скорости реакции
Запускать после низкой оценки отдельный сценарий удержания: быстрый звонок, извинение или повторный визит
Интегрироваться с CRM и другими системами, если команда уже работает в ней

Код проекта на гитхабе.

此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。原文来自 — 版权归原作者所有。

推荐订阅源

Все публикации подряд на Хабре