ИИ в интернет-магазине: 30 дней без остановки продаж

Шаблон 4. Чек-лист ручной проверки карточки. Он печатается и лежит у проверяющего: числа в тексте совпадают с таблицей поставщика (мощность, объём, размеры, вес); каждая функция из текста есть в данных; материал указан так же, как у поставщика; нет слов с оттенком гарантии, которых нет в данных; комплектация не расширена; нет запрещённых слов; заголовок не длиннее 70 знаков. Семь пунктов, одна-две минуты. Если проверка занимает дольше, значит, в карточке слишком много текста: упростите шаблон.

Шаблон 5. Промпт для автозапчастей.

Ты — редактор интернет-магазина автозапчастей. Оформи карточку

ТОЛЬКО по данным ниже.

ПРАВИЛА:

1. Применимость (марка, модель, год, двигатель) копируй дословно.

Не расширяй список автомобилей и не обобщай

(«подходит для большинства авто» — запрещено).

2. Номера OEM и кросс-номера копируй символ в символ.

3. Если применимость не указана, выведи строку:

«ТРЕБУЕТСЯ РУЧНАЯ ПРОВЕРКА ПРИМЕНИМОСТИ» и остановись.

4. Не пиши про срок службы, если его нет в данных.

ДАННЫЕ:

[строка]

В автозапчастях ошибка применимости превращается в возврат и испорченное доверие, поэтому правило 3 заставляет модель остановиться, а не угадывать. Эти и другие промпты собраны в Приложении А.

ПРИМЕР ИЗ ПРАКТИКИ

Все числа в этой истории условные, они нужны, чтобы показать ход мысли.

Ольга садится с карандашом и считает. Партия: сорок чайников. Лена засекла время: вручную на карточку уходит 22 минуты. Вся партия это 40 × 22 = 880 минут, почти 14,7 часа. По условной ставке 400 рублей в час это около 5 900 рублей.

Теперь конвейер. Первая партия требует настройки: паспорт карточки, приведение данных к единому виду, подбор промпта. Лена оценивает это в восемь часов. Дальше на каждую карточку уходит в среднем семь минут: проверка и доработка, где-то быстрее, где-то глубже. 40 × 7 = 280 минут, около 4,7 часа. Всего первая партия обходится в 12,7 часа, то есть около 5 100 рублей, без учёта подписки на нейросеть, о ней в главе 8.

— Выигрыш копеечный, — говорит Артём, заглянув через плечо.

— На первой партии да, — отвечает Ольга. — А на второй настройка уже сделана. Четыре с половиной часа вместо четырнадцати с лишним, разница десять часов, четыре тысячи рублей. Настройка в восемь часов возвращается меньше чем за одну партию.

Но она замечает и хрупкое место. Если семь минут превратятся в четырнадцать (данные поставщика плохие, всё приходится править), экономия сократится вдвое. А если половину полей приходится искать вручную, конвейер выигрыша не даст вообще. Поэтому станция 1, подготовка данных, определяет почти всё.

Для магазина одежды картина похожая. Допустим, 120 позиций, 18 минут на ручное описание, пять минут при конвейере и десять часов настройки (дольше, потому что нужны размерные сетки и составы тканей). Вручную это 36 часов. С конвейером 10 + 10 = 20 часов на первой партии, дальше около 10 часов. Общее правило видно из двух примеров: чем больше однотипных карточек, тем быстрее окупается настройка. Для магазина с тридцатью товарами в год конвейер, скорее всего, не нужен.

Есть и таблица «до и после», которую Ольга вешает над рабочим местом Лены.

Показатель

До (вручную)

После (конвейер)

Время на карточку

22 мин

7 мин

Единый стиль

зависит от настроения

задан шаблоном

Ошибки в цифрах

случайные опечатки

редкие, ловятся автопроверкой

Риск выдуманных функций

нет

есть, закрывается проверкой

Обратите внимание на последнюю строку: конвейер добавляет новый риск, которого раньше не было. Он управляем, но только если станции 3 и 4 действительно работают.

ГРАБЛИ, НА КОТОРЫЕ НАСТУПАЮТ ВСЕ

Самая частая история: пустые ячейки вместо «НЕТ ДАННЫХ». Человек думает, что раз данных нет, модель о них и не заговорит. А она воспринимает пустоту как приглашение дописать. Занимает минуты, а экономит часы: перед генерацией заполните все пустые ячейки явной пометкой.

Другая: генерация и проверка в одном запросе. «Напиши карточку и проверь себя» звучит экономно, но модель склонна подтверждать собственную работу. Проверка всегда отдельным запросом с отдельной ролью.

Третья: публикация без выборки. «Выглядит нормально, загружаем». Через две недели покупательница звонит с вопросом, где обещанная в описании функция. Правило выборки (все карточки с пометками, все замечания автопроверки, 10 % остальных) должно быть записано и выполняться без исключений.

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

Пятая: загрузка сорока товаров одним запросом. В конце партии качество падает, модель начинает смешивать данные соседних строк. Пачки по 5–10 строк скучнее, зато надёжнее.

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

Седьмая: использование данных, которые нельзя проверить. Поставщик пишет «подходит для детей», а сертификата нет, и модель это повторит. В паспорте карточки пометьте поля с юридическим оттенком (безопасность, медицинские и детские свойства) как «только с подтверждающим документом».

КАК ПРОВЕРИТЬ, ЧТО РАБОТАЕТ

Смотрите на две вещи: сколько карточек проходит ручную проверку без правок (эта доля должна расти от партии к партии) и сколько обращений покупателей и возвратов приходит с причиной «не соответствует описанию» (их должно быть не больше, чем до внедрения). Если время проверки одной карточки сравнялось со временем написания с нуля, конвейер бесполезен, и пора искать причину в данных поставщика.

Критерий «внедрено»: у вас есть паспорт карточки, зафиксированная версия промпта и журнал ошибок, а последние две партии прошли весь цикл с выборочной проверкой.

ВОПРОСЫ ВЛАДЕЛЬЦЕВ

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

«Данных у поставщика почти нет. Может, нейросеть сама найдёт информацию?» Если у вашего сервиса есть доступ к поиску, он может найти информацию, но вы не контролируете источник и точность. Для характеристик, влияющих на покупку, берите данные только у производителя или поставщика. Допустимая роль ИИ здесь: помочь составить список вопросов поставщику.

«Не накажет ли поисковик за одинаковые описания?» Поисковые системы действительно не любят дублированный контент. Если все карточки собираются из одного шаблона и отличаются только цифрами, они выглядят однотипно. Это не обязательно приводит к санкциям, но снижает ценность страниц. Добавляйте в шаблон блоки, зависящие от особенностей товара, и не публикуйте тысячу почти одинаковых текстов сразу.

«Можно ли загружать в чат всю таблицу поставщика с ценами?» Описания товаров обычно не содержат персональных данных, поэтому риск ниже, чем с клиентской базой. Но закупочные цены и условия работы с поставщиком коммерчески чувствительны. Передавайте в запрос только поля, нужные для описания. Подробнее о данных в главе 5.

ЧТО СДЕЛАТЬ ПРЯМО СЕЙЧАС

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

Когда паспорт готов, заполните пустые ячейки словами «НЕТ ДАННЫХ», запустите шаблон 1 на каждом из пяти товаров по одному, а затем шаблон 2. Сверьте результат с чек-листом проверки. Запишите, сколько ошибок нашла автопроверка и сколько вы заметили сами. Если автопроверка пропустила хотя бы одну, это не провал, а повод сделать её промпт строже. И вернитесь к карте из пяти задач, которую вы составили во Введении: если карточки там есть, отметьте, что процесс запущен.

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

ГЛАВА 2. Умная поддержка: автоматизация ответов на вопросы о заказах, доставке и возвратах

СИТУАЦИЯ

Артём, менеджер по заказам в магазине Ольги, приходит в понедельник и открывает чат на сайте. За выходные накопилось тридцать семь обращений. Он начинает отвечать сверху вниз.

«Где мой заказ?» Открывает CRM, ищет по номеру, копирует статус, пишет ответ. Три минуты. «Когда придёт посылка?» Ещё одна проверка, ещё три минуты. «Можно ли вернуть кастрюлю?» Он открывает страницу с условиями возврата, перечитывает её, потому что точный срок не помнит, и пишет ответ. «Подскажите, подойдёт ли эта крышка к кастрюле на пять литров?» Тут нужно открыть две карточки и сравнить диаметры.

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

— Я заметил странную вещь, — говорит Артём Ольге за обедом. — На сложные обращения у меня почти не осталось сил. А именно по ним решают, вернётся человек или нет. Ответ про статус клиент не запомнит. Ответ про разбитую тарелку запомнит надолго.

Ольга кивает. Проблема не в том, что обращений много. Проблема в том, что лёгкие и трудные обращения лежат в одной куче.

В ЧЁМ НАСТОЯЩАЯ ПРОБЛЕМА

Симптом: «поддержка не справляется, ответы приходят поздно». Причин две, и они разные.

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

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

Отсюда формулировка задачи: не «поставить чат-бота», а «разделить обращения на типы, записать правила для типовых, автоматизировать ответы на них и передавать сложные человеку без потери контекста».

Отдельно о слове «бот». Многие представляют бота как программу, которая сама общается с клиентом в чате. Это один из вариантов, и самый рискованный. Есть более безопасные: ИИ готовит черновик ответа, а человек нажимает «отправить». Мы разберём обе схемы и скажем прямо, когда какая подходит.

КАК ЭТО РАБОТАЕТ

Система поддержки на основе ИИ состоит из четырёх частей.

База знаний: документ (или несколько), где записаны правила магазина: условия возврата, сроки и способы доставки, способы оплаты, гарантия, график работы, ответы на частые вопросы. Это единственный источник правды. Всё, чего нет в базе знаний, модель не вправе утверждать.

Классификатор: первый шаг обработки любого обращения, определение его типа. Например: «статус заказа», «сроки доставки», «возврат и обмен», «вопрос о товаре», «жалоба», «прочее». Для каждого типа заранее решено, что делать.

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

Маршрутизатор: правило, кому уходит обращение. ИИ отвечает сам (только самые безопасные типы), ИИ готовит черновик для человека (большинство типов) или обращение сразу уходит человеку без участия ИИ (жалобы, споры, угрозы, юридические вопросы).

У такой системы три уровня самостоятельности. Уровень A, подсказчик: ИИ ничего не отправляет, он готовит черновик, оператор читает, правит и отправляет. Риск минимальный, выигрыш по времени заметный, и с этого уровня стоит начинать. Уровень B, автоответ на узкий класс вопросов: ИИ или простое правило отвечает само, но только там, где ответ статичен и безопасен (часы работы, способы оплаты). Уровень C, автоответ с данными заказа: система сама сообщает статус, подставляя данные из CRM. Это самый сложный уровень, нужна интеграция, и здесь, скорее всего, понадобится помощь разработчика или конструктор сценариев без программирования (в главе 6 разберём, что это такое). Не рассчитывайте на него в первую неделю.

Важная оговорка про данные. Чтобы ИИ видел статус заказа, ему нужно передать номер заказа и статус, но не имя, телефон и адрес клиента. Передавайте минимум. Подробно об этом в главе 5.

ПОШАГОВАЯ ИНСТРУКЦИЯ

Процедура ведёт от хаоса к работающему уровню A, затем к частичному уровню B.

Шаг 1. Соберите 100 последних обращений. Выгрузите из чата, почты, мессенджеров. Это материал для анализа. Если переписка хранится в нескольких местах, начните с самого загруженного канала.

Шаг 2. Уберите персональные данные. Замените имена на «Клиент», телефоны и адреса удалите, номера заказов оставьте, но не добавляйте рядом ФИО. Делайте это до любой загрузки в нейросеть. Быстрый способ: поиск и замена в таблице.

Шаг 3. Разложите обращения по типам. Можно вручную, можно с помощью ИИ: попросите его предложить 8–10 категорий и разложить по ним вашу выборку (шаблон 1). Проверьте результат глазами хотя бы на двадцати обращениях.

Шаг 4. Посчитайте долю каждого типа. Получите таблицу вроде «статус заказа: 31, возврат: 18, доставка: 15, товар: 17, жалоба: 6, прочее: 13». Это ваша реальная структура обращений. Цифры чужих магазинов вам не подходят.

Шаг 5. Выберите 3–4 самых массовых безопасных типа. Критерий «безопасный»: ответ однозначен, и ошибка не приводит к денежным потерям. Обычно это статус, сроки доставки, общие условия возврата, часы работы.

Шаг 6. Напишите базу знаний. Для каждого выбранного типа запишите правила простым языком, с точными числами и исключениями. Например: «Возврат возможен в течение 14 дней с момента получения. Товар должен быть без следов использования. Деньги возвращаются в течение 10 рабочих дней после получения товара на склад». Шаблон 2 поможет структурировать документ.

Шаг 7. Запишите «стоп-темы»: ситуации, в которых ИИ не отвечает, а передаёт человека. Жалоба, повреждённый товар, угроза обратиться в суд или в Роспотребнадзор, вопросы о компенсации, упоминание здоровья, оскорбления, любые индивидуальные скидки. Готовый список в шаблоне 4.

Шаг 8. Составьте промпт подсказчика (шаблон 3). Вставьте в него базу знаний и стоп-темы.

Шаг 9. Проверьте на 30 обращениях из своей выборки. Для каждого получите черновик и оцените по трём критериям: верно ли по существу, не выдумано ли что-то, подходит ли тон. Если модель придумывает условия, которых нет в базе, добавьте недостающее правило или усильте запрет в промпте.

Шаг 10. Доработайте базу знаний. Любое обращение, на которое модель ответила плохо из-за отсутствия правила, превращается в новую запись в базе. Это нормальный итеративный процесс: база растёт вместе с практикой.

Шаг 11. Запустите уровень A на одном канале и с одним оператором. Он получает черновики, правит и отправляет. Две недели ведите учёт: сколько времени на ответ, сколько правок.

Шаг 12. Введите правило эскалации. Любое обращение из списка стоп-тем или с негативной окраской оператор берёт сам, без черновика. В инструкции достаточно одной фразы: «сомневаешься, берёшь сам».

Шаг 13. Подключите уровень B на статичных вопросах. Если ваш чат или мессенджер позволяет настроить быстрые ответы по ключевым словам, создайте их для часов работы, способов оплаты и адреса самовывоза. Это обычные функции многих платформ, ИИ для них не нужен. Если ваша платформа такого не умеет, не усложняйте: оставайтесь на уровне A.

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

Шаг 15. Раз в неделю разбирайте ошибки. Откройте 10 случайных переписок, найдите неудачные ответы, внесите правки в базу знаний и промпт. Без этого качество стоит на месте.

РАБОЧИЕ ШАБЛОНЫ

Шаблон 1. Промпт классификации обращений.

Ты — аналитик поддержки интернет-магазина. Ниже список обращений

клиентов (персональные данные удалены).

Задача:

1. Предложи от 8 до 10 категорий, в которые можно разложить эти обращения.

2. Для каждого обращения укажи одну категорию.

3. Выведи таблицу: номер обращения | категория.

4. В конце выведи сводку: категория | количество обращений.

Правила:

- Если обращение подходит под две категории, выбери ту, которая

требует более внимательной обработки.

- Категорию «Жалоба» используй для любых обращений с недовольством

или упоминанием проблем с товаром или доставкой.

- Не придумывай содержание обращений, работай только с текстом.

ОБРАЩЕНИЯ:

[список]

Правило про выбор «более внимательной» категории защищает от ошибки, когда жалоба маскируется под вопрос о статусе.

Шаблон 2. Структура базы знаний. Один документ, разделы по темам, в каждом разделе пять строк.

РАЗДЕЛ: Возврат товара

Правило: [точная формулировка с числами]

Исключения: [что не подлежит возврату]

Что нужно от клиента: [какие данные, документы]

Когда передавать человеку: [условия]

Дата последнего обновления: [дата]

Поле «Дата последнего обновления» не формальность. Если вы изменили условия, но забыли обновить базу, ИИ будет уверенно сообщать старые. Раз в месяц проверяйте даты.

Шаблон 3. Промпт подсказчика для оператора.

Ты — помощник оператора интернет-магазина. Подготовь черновик ответа

клиенту. Оператор проверит и отправит его сам.

ПРАВИЛА:

1. Отвечай ТОЛЬКО на основе блока БАЗА ЗНАНИЙ.

2. Если в базе знаний нет ответа на вопрос, не придумывай.

Выведи: «НЕТ ДАННЫХ В БАЗЕ. Нужен ответ оператора» и кратко

перечисли, какой информации не хватает.

3. Не обещай скидки, компенсации, сроки и исключения из правил.

4. Если обращение содержит что-то из СТОП-ТЕМ, выведи:

«СТОП-ТЕМА: [какая]. Передать оператору» и не пиши черновик.

5. Тон: вежливый, спокойный, на «вы», без восклицательных знаков

и шаблонных фраз вроде «Спасибо за ваше обращение, оно очень

важно для нас».

6. Длина: до 600 знаков.

7. В конце черновика всегда добавь: «Если останутся вопросы,

оператор поможет в чате».

БАЗА ЗНАНИЙ:

[вставить]

СТОП-ТЕМЫ:

[вставить]

ОБРАЩЕНИЕ КЛИЕНТА:

[вставить]

ДАННЫЕ ЗАКАЗА (если нужны):

[только номер заказа и статус, без имени и контактов]

Правила 2 и 4 дают два безопасных «выхода»: модель может сказать «не знаю» или «это не моё». Без них она будет стремиться ответить во что бы то ни стало.

Шаблон 4. Список стоп-тем (поправьте под себя): жалоба на качество, повреждение или брак; любое упоминание суда, юриста, Роспотребнадзора, прокуратуры; вопросы о здоровье, безопасности, аллергии; просьба о скидке, компенсации, исключении из правил; спор о деньгах, двойное списание, ошибка оплаты; оскорбления, эмоциональные сообщения, угрозы написать отзыв; заказ юридического лица, крупный опт; просьба передать данные другого человека. Последние два пункта часто забывают. Опт требует индивидуального расчёта, а просьба «скажите адрес доставки по заказу моей жены» может быть попыткой получить чужие данные. Список в виде готового блока есть в Приложении А.

Шаблон 5. Пример черновика по статусу заказа (уровень A).

Ситуация: клиент спрашивает «где мой заказ №12345?»

Данные заказа: статус «Передан в службу доставки»,

дата передачи 15.10, ориентировочный срок 3–5 рабочих дней.

Готовый черновик:

«Ваш заказ №12345 передан в службу доставки 15 октября.

Ориентировочный срок доставки по условиям магазина составляет

3–5 рабочих дней с момента передачи. Как только заказ

поступит в пункт выдачи или будет передан курьеру,

вы получите уведомление. Если останутся вопросы, оператор

поможет в чате.»

В ответе только то, что есть в данных, и слово «ориентировочный» там, где точной даты нет. Фраза «по условиям магазина» защищает от обещания, которое вы не можете выполнить.

ПРИМЕР ИЗ ПРАКТИКИ

Все числа в этой истории условные, это модель для разбора, а не реальный результат.

Ольга берёт цифры по своему магазину. Обращений в месяц около 900. Анализ сотни обращений показал: статус заказа 30 %, сроки доставки 15 %, возврат и обмен 15 %, вопросы о товаре 20 %, жалобы 7 %, прочее 13 %. Оператор отвечает в среднем за четыре минуты, час работы оператора обходится условно в 350 рублей.

Она выбирает безопасные типы для подсказчика: статус (30 %), сроки (15 %) и общие условия возврата (из 15 % возьмём 10 %, остальное нестандартные случаи). Итого 55 % обращений, то есть 495 в месяц.

До внедрения: 900 × 4 минуты = 3 600 минут, 60 часов в месяц, 21 000 рублей. С подсказчиком оператор тратит на безопасные обращения не четыре минуты, а полторы (читает черновик, правит, отправляет): 495 × 1,5 = 742,5 минуты, около 12,4 часа. Остальные 405 обращений идут по-старому: 405 × 4 = 1 620 минут, 27 часов. Итого 39,4 часа вместо 60. Экономия 20,6 часа в месяц, по условной ставке около 7 200 рублей.

— Это не про увольнение, — сразу говорит Ольга Артёму. — Это двадцать часов, которые ты потратишь на жалобы и сложные случаи. Помнишь, на что у тебя не хватало сил?

Но расчёт хрупкий. Если реальное время правки черновика окажется три минуты вместо полутора, экономия сократится почти до нуля, поэтому в первые две недели стоит замерять реальное время. Если база знаний неполная и 40 % черновиков приходится переписывать целиком, выигрыш исчезнет. И расчёт не учитывает подписку на нейросеть и время на ведение базы знаний (по два-три часа в неделю на старте): это добавим в главе 8.

Совсем иначе выглядит магазин автозапчастей. Допустим, 600 обращений в месяц, из них 40 % вопросы «подойдёт ли к моему автомобилю». Автоподсказки по базе знаний здесь рискованны: ошибка в применимости означает возврат. Разумная схема другая: ИИ готовит черновик со списком данных, которые надо уточнить у клиента (VIN, то есть 17-значный идентификационный номер автомобиля, год, двигатель), а подтверждение применимости делает человек по каталогу. Выигрыш меньше, зато нет риска продать не ту деталь.

Показатель

До

После (уровень A)

Среднее время ответа на типовой вопрос

4 мин

1,5 мин

Единообразие ответов о возврате

зависит от оператора

по базе знаний

Время на жалобы

что останется

выделенный запас

Риск ошибки в ответе

забывчивость

выдумка модели (закрывается правилами 2 и 4)

ГРАБЛИ, НА КОТОРЫЕ НАСТУПАЮТ ВСЕ

Первая история начинается с желания поставить «умного бота» сразу. Магазин отдаёт ИИ общение с клиентами без накопленного опыта, и первая же выдуманная скидка или неверный срок возврата превращается в претензию. Начинайте с уровня A и переходите выше только после месяца статистики.

Вторая: размытая база знаний. «Возврат возможен в разумные сроки». Модель не знает, что это значит, и придумает. В базе должны быть числа, даты, условия и исключения.

Третья: нет стоп-тем. ИИ вежливо отвечает на гневную жалобу и подливает масла в огонь. Список стоп-тем и обязательная передача человеку решают это.

Четвёртая: передача ИИ персональных данных. Оператор копирует в запрос всю переписку с именем, телефоном и адресом. Нужна короткая инструкция: копируется только текст вопроса и номер заказа. Подробнее в главе 5.