WooCommerce Phone Orders & Manual Orders - Плагин WordPress

Руководство по WooCommerce Phone Orders & Manual Orders: как принимать заказы по телефону и вручную

WooCommerce Phone Orders & Manual Orders нужен не для украшения витрины, а для рабочей ситуации, когда заказ приходит не через обычную корзину: клиент звонит, пишет в чат, присылает список товаров по почте, приходит в офлайн-точку или повторяет прошлую закупку. В таком сценарии менеджеру важно не открывать десяток вкладок и не пересчитывать всё вручную, а быстро собрать заказ внутри WooCommerce, выбрать клиента, товары, доставку, оплату, купон, дополнительную плату и сохранить результат как нормальный заказ магазина.

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

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

Задачи, для которых плагин действительно нужен

Ручной заказ в WooCommerce можно создать и средствами ядра: открыть WooCommerce > Orders, нажать Add order, выбрать клиента, добавить позиции, пересчитать итоги и отправить письмо с оплатой. Для одного-двух заказов в месяц этого часто достаточно. Проблема начинается там, где ручной ввод становится частью операционного процесса: оператору нужно искать товар по названию или SKU во время разговора, добавлять вариации, учитывать купон, выбрать доставку, принять оплату, сохранить примечание и не ошибиться в адресе.

WooCommerce Phone Orders & Manual Orders закрывает именно эту разницу между "можно создать вручную" и "можно быстро принять заказ как рабочий процесс". По данным страницы IgniteWoo, плагин использует умный поиск товаров по названию или SKU, позволяет выбрать существующего клиента или добавить нового, выбрать доставку и способ оплаты, ввести платёжные данные и разместить заказ. Там же указано, что он работает не только с простыми товарами, но и с вариативными, сгруппированными, составными, комплектными, подписочными и другими сложными типами, если соответствующие расширения магазина это поддерживают.

Самые понятные сценарии:

• Телефонные продажи. Клиент диктует товары и адрес, менеджер сразу собирает заказ и видит итоговую сумму.
• Повторные B2B-заказы. Постоянный покупатель часто берёт похожий набор, поэтому удобно загрузить существующий заказ как основу для нового.
• Заказы из офлайн-точки. Сотрудник вводит покупку в WooCommerce, чтобы склад, отчёты и история клиента оставались едиными.
• Специализированные товары. Если товар требует дополнительных полей, выбранных опций или комментариев, заказ лучше оформлять в той же логике, что и обычную покупку.
• Клиенты без аккаунта. Плагин позволяет работать с гостем или создать клиента во время оформления, если это нужно для истории заказов.

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

Когда WooCommerce Phone Orders & Manual Orders подходит, а когда лучше выбрать другой путь

Плагин хорошо подходит магазинам, где ручные заказы должны попадать в тот же поток, что и обычные онлайн-заказы. Это важно для склада, отчётов, писем, CRM-синхронизаций, статусов, аналитики и истории клиента. Если заказ оформлен вне WooCommerce, команда получает отдельный источник правды: кассовая программа, таблица, почтовый ящик, заметки менеджера. Чем больше таких источников, тем проще потерять оплату, забыть отгрузку или дважды списать остаток.

Второй сильный случай - магазины со сложным каталогом. Простая ручная форма WooCommerce неудобна, когда нужно быстро найти товар по SKU, выбрать вариацию, добавить комплект, учесть индивидуальную цену, купон, плату за услугу или нестандартную доставку. IgniteWoo отдельно отмечает поддержку дополнительных данных для специализированных товаров, включая формы Product Add-on Forms и сторонние решения вроде Gravity Forms. Это не означает гарантированную совместимость с любым расширением, но показывает направление продукта: он рассчитан на реальные каталоги, а не только на три простых товара.

Плагин может не подойти, если ваша задача - публичная фронтенд-форма для оптовых покупателей, где сам клиент набирает товары из таблицы. В этом случае ближе решения класса WooCommerce Product Table или специализированные формы быстрого заказа. Он также может быть избыточен, если у магазина один менеджер, редкие ручные заказы и нет сложных тарифов. Для таких сайтов сначала стоит освоить стандартное создание заказа в WooCommerce и payment link behavior.

Отдельный случай - приём банковских карт по телефону. Плагин заявляет работу с большим количеством платёжных шлюзов и возможность обработки оплаты, но правила безопасности зависят не только от WooCommerce, а от конкретного платёжного провайдера, виртуального терминала, политики хранения данных и требований PCI. Не вводите и не сохраняйте карточные данные в произвольные поля заказа. Если менеджер принимает оплату по телефону, используйте официально поддерживаемый MOTO/virtual terminal-сценарий вашего провайдера или отправляйте клиенту защищённую ссылку на оплату.

Что проверить перед установкой на рабочем магазине

Перед установкой важно понять не только "поддерживается ли WooCommerce", но и какие именно части магазина участвуют в ручном заказе. WooCommerce Phone Orders & Manual Orders работает рядом с заказами, оплатами, доставкой, налогами, купонами, сложными товарами и пользовательскими полями. Это зона, где маленький конфликт может проявиться не визуальной ошибкой, а неверным итогом заказа.

Совместимость WooCommerce и HPOS

На странице продукта указана совместимость с WooCommerce 7.0 или новее, а в changelog отмечена совместимость с WooCommerce 10.x и улучшения для sequential order number plugins при включённом HPOS compatibility mode. Для владельца магазина это означает простое правило: перед включением на рабочем сайте проверьте текущую версию WooCommerce, режим хранения заказов и список расширений, которые меняют номера заказов, статусы, оплату, доставку или состав заказа.

HPOS переносит данные заказов из старой связки _posts/_postmeta в отдельные таблицы WooCommerce. WooCommerce рекомендует проверять несовместимые расширения в WooCommerce > Settings > Advanced > Features. Если магазин уже использует HPOS, тестируйте плагин в том же режиме. Если HPOS ещё не включён, не совмещайте миграцию хранения заказов и установку нового ручного order workflow в один день.

Платежи и способ подтверждения оплаты

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

Нельзя считать, что любой онлайн-шлюз автоматически подходит для телефонного ввода карты менеджером. WooCommerce Payment Gateway API отдельно подчёркивает, что прямые шлюзы требуют серверной безопасности и могут затрагивать PCI compliance. Если ваш провайдер не описывает MOTO или virtual terminal, лучше не импровизировать.

Доставка, налоги, купоны и сложные товары

Проверьте, какие механики участвуют в типовом телефонном заказе:

• Нужен ли расчёт доставки по адресу, весу, зонам или carrier API.
• Есть ли товары с вариациями, комплектами, composite/bundle-логикой или подписками.
• Используются ли купоны, wholesale pricing, tiered pricing, dynamic discounts или ручные скидки.
• Есть ли дополнительные поля checkout, product add-ons, подарочные сертификаты или пожертвования.
• Должен ли заказ сразу уменьшать остаток или сначала оставаться на удержании.

Соберите один тестовый заказ для каждого сложного типа товара. Не ограничивайтесь простым товаром за условную сумму: такой тест почти ничего не скажет о реальном магазине.

Установка и первая проверка после активации

Установка премиального WooCommerce-расширения обычно выполняется через загрузку ZIP-файла в Plugins > Add New Plugin > Upload Plugin, затем Install Now и Activate. Если магазин использует отдельную систему обновлений поставщика, следуйте документации продавца. В любом случае сначала подготовьте резервную копию и staging-копию сайта, потому что плагин работает с заказами и платежами.

После активации не переходите сразу к реальным звонкам. Сначала найдите страницу настроек или пункт меню плагина в админке WordPress. В публичной странице продукта IgniteWoo показаны скриншоты простых настроек и страницы ввода ручного заказа, но точное расположение пунктов может отличаться в зависимости от версии и конфигурации магазина. В старых обсуждениях встречался путь интеграционных настроек WooCommerce, однако в статье лучше ориентироваться на фактический интерфейс вашей установленной версии.

Минимальная проверка доступности

Войдите под администратором и убедитесь, что интерфейс ручного заказа открывается без ошибок JavaScript, пустых блоков и бесконечной загрузки. Затем проверьте доступ под ролью, которая будет реально принимать звонки. Если менеджеры работают как Shop manager, им не всегда нужны права администратора, но им нужны права на создание заказов, чтение клиентов, просмотр товаров и работу с WooCommerce.

Если интерфейс виден только администратору, не расширяйте права вслепую. Сначала уточните, какие роли поддерживает плагин, и проверьте, не ограничивает ли доступ отдельное security-расширение. Для магазинов с call center лучше завести отдельную роль или аккуратно настроить capabilities через проверенный role editor, а не давать всем сотрудникам полный админ-доступ.

Тест поиска товара и клиента

Проверьте поиск по нескольким типам данных: название товара, SKU, вариация, товар с add-on, существующий клиент, гость, новый клиент. IgniteWoo указывает smart search по названию и SKU, поэтому именно эти два сценария должны попасть в первичный тест. Если SKU не находится, проверьте, заполнены ли SKU у вариаций, нет ли конфликтов с плагином поиска и не ограничивает ли результат кеш админки.

Контрольное сохранение заказа

Создайте тестовый заказ с недорогим товаром, адресом, доставкой и безопасным способом оплаты. После сохранения откройте его в обычном списке WooCommerce > Orders. Заказ должен выглядеть как полноценный заказ WooCommerce: иметь позиции, клиента или гостевые данные, адрес, итог, налоги, способ доставки, способ оплаты, статус и заметки. Это ключевая проверка: плагин может иметь собственный быстрый интерфейс, но итог должен жить в стандартной системе заказов.

Настройки, которые стоит пройти перед первым реальным звонком

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

Клиент: гость, существующий аккаунт или новый пользователь

Страница IgniteWoo подтверждает два базовых варианта: заказ для гостя и добавление нового клиента с регистрацией аккаунта во время оформления. Выбор влияет на оплату, историю заказов и поддержку. Если клиент постоянный, выбирайте существующий аккаунт: заказ попадёт в историю My account, а менеджер сможет быстрее повторить прошлую закупку. Если человек делает разовый заказ и не хочет регистрацию, гостевой заказ проще.

У WooCommerce есть важное правило payment link behavior. Если заказ привязан к аккаунту, оплатить ссылку должен именно этот пользователь после входа. Если администратор или другой человек открывает такую ссылку, WooCommerce может показать сообщение, что заказ нельзя оплатить. Это не всегда конфликт плагина. Для гостевого заказа ссылка обычно проще, но WooCommerce может запросить подтверждение billing email. Поэтому в инструкцию для менеджеров стоит добавить вопрос: "У клиента есть аккаунт или оформляем как гостя?"

Товары и вариации

Для простых товаров достаточно найти позицию и добавить количество. Для вариативных товаров менеджер должен видеть нужный атрибут: размер, цвет, упаковку, длительность подписки или другой параметр. Если магазин продаёт composite/bundled products, подписки или add-on forms, сделайте отдельную проверку для каждого типа. IgniteWoo заявляет поддержку многих сложных типов, но практическая совместимость зависит от конкретных расширений и их текущих версий.

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

Цены, купоны, fees и ручные корректировки

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

Сформулируйте внутренние правила:

• Купон применяется только если он уже существует в WooCommerce и клиент имеет право его использовать.
• Ручная цена используется для согласованной скидки, замены товара, индивидуального B2B-условия или исправления известного edge case.
• Fee получает понятное название, например "Упаковка", "Срочная обработка" или "Дополнительная услуга", а не абстрактное "Доплата".
• Кастомная доставка применяется только там, где автоматический тариф недоступен или менеджер получил подтверждённую стоимость.

Доставка и налоги

WooCommerce умеет пересчитывать налоги по адресу и настройкам магазина. В стандартном order editor действие Recalculate пересчитывает итоги после изменения товаров, купонов или доставки. В ручном workflow принцип тот же: сначала вводятся товары и адрес, затем выбирается доставка, затем проверяются налоги и итог.

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

Оплата, статус и письма

Для заказа, который клиент должен оплатить позже, логичен статус Pending payment и письмо с оплатой. Для офлайн-метода, где оплату нужно подтвердить вручную, часто используется On hold. Для оплаченного заказа физического товара обычно ожидается Processing, после чего склад выполняет заказ и переводит его в Completed. Не меняйте статусы только ради удобного цвета в списке заказов: статус запускает письма, уменьшение остатков и интеграции.

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

Как менеджеру собрать телефонный заказ без потери данных

Рабочий сценарий должен быть коротким, но не хаотичным. Если менеджер просто "заполняет как получится", команда быстро получает разнородные заказы: где-то нет телефона, где-то не выбрана доставка, где-то применена ручная скидка без объяснения, где-то клиент привязан не к тому аккаунту. Ниже - порядок, который можно адаптировать под свой магазин.

Шаг 1. Определить клиента и канал связи

Начинайте не с товара, а с клиента. Спросите имя, телефон, email и есть ли у него аккаунт. Если клиент постоянный, найдите его в системе. Если это новый покупатель, решите, создаёте ли аккаунт или оформляете гостевой заказ. Для B2B и повторных заказов аккаунт почти всегда полезнее, потому что история закупок помогает повторить прошлый набор и видеть договорённости.

Шаг 2. Добавить товары по SKU или точным вариантам

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

Шаг 3. Проверить дополнительные поля

Для товаров с add-ons, формами или кастомным вводом проверьте, что менеджер заполнил все обязательные данные. Это может быть текст гравировки, размер упаковки, дата услуги, комментарий к сборке, выбор комплекта, файл или иной параметр. Если поле влияет на производство или доставку, оно должно быть видно не только в интерфейсе плагина, но и в итоговом заказе.

Шаг 4. Выбрать доставку и оплату

После ввода адреса рассчитайте или выберите доставку. Если автоматический тариф не появился, не вводите произвольную цену без причины: проверьте адрес, зону доставки, вес, наличие способа доставки и условия бесплатной доставки. Затем выберите оплату. Если клиент платит позже, используйте безопасную ссылку. Если оплата уже получена вне WooCommerce, добавьте заметку с допустимым идентификатором, но не с чувствительными платёжными данными.

Шаг 5. Сохранить заказ и проверить его в обычном WooCommerce

После сохранения откройте заказ в списке WooCommerce > Orders. Проверьте статус, товары, количество, налоги, доставку, billing/shipping address, email, телефон и order notes. Если магазин использует внешнюю CRM, складскую систему, сервис доставки или бухгалтерскую синхронизацию, проверьте, что ручной заказ попадает туда так же, как обычный заказ.

Мини-итог для менеджера простой: заказ считается принятым только после проверки в стандартной карточке WooCommerce. Быстрый интерфейс помогает создать заказ, но контрольная точка - обычная order page.

Повторные заказы, удержание и копирование как отдельная сила продукта

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

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

Что обязательно перепроверять при повторе заказа

• Наличие товаров и статус вариаций.
• Текущие цены, налоговый режим и правила скидок.
• Адрес доставки и контактное лицо.
• Способ оплаты и статус, который должен получить новый заказ.
• Комментарии к прошлому заказу, которые могли быть разовыми и не должны попасть в новый.

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

Не используйте копирование как замену проверке. Оно экономит время на вводе, но не подтверждает актуальность цены, доставки, налога, скидки и остатков.

Ручные цены, произвольные товары и fees: как не сломать отчёты

Возможность добавить произвольный товар, поменять цену или добавить fee выглядит удобно, но для отчётности это зона повышенного внимания. Обычный товар имеет SKU, категорию, налоговый класс, складской статус и историю продаж. Произвольная строка может не иметь этих связей. Ручная цена может быть правильной для клиента, но непонятной для аналитики. Fee может быть полезной услугой, но если менеджеры называют её каждый раз по-разному, отчёты становятся шумными.

Когда оправдана ручная цена

Ручная цена уместна для индивидуального согласованного предложения, компенсации, частичной замены, B2B-условия или товара с нестандартной комплектацией. Она не должна становиться способом "быстро исправить всё", потому что потом трудно понять, почему цена отличается от каталога. Если у магазина есть wholesale pricing или tiered pricing, сначала проверьте автоматические правила. Ручную цену используйте как исключение, а не как ежедневную норму.

Как назвать дополнительные fees

Название fee должно объяснять клиенту и бухгалтерии, за что добавлена сумма. Хорошие варианты: "Срочная обработка", "Индивидуальная упаковка", "Дополнительная доставка", "Монтажная услуга". Плохие варианты: "Разное", "Плюс", "Доплата", "Сервис". Если fee облагается налогом, это нужно проверить в итогах заказа. Если не облагается, убедитесь, что это соответствует правилам магазина и законодательным требованиям вашей юрисдикции.

Произвольный товар как временное решение

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

Проверка результата: что должно быть видно после сохранения заказа

Проверка результата нужна не только после установки. Её стоит выполнять после обновления WooCommerce, плагина, платёжного шлюза, расширения доставки, tax-сервиса, discount-плагина и включения HPOS. Ручные заказы затрагивают много связей, поэтому каждая крупная техническая перемена должна проходить через один контрольный сценарий.

Откройте созданный заказ в стандартной карточке WooCommerce и пройдите по чек-листу:

• Клиент выбран правильно: существующий аккаунт или гость соответствует сценарию.
• Billing email и телефон заполнены, потому что они нужны для оплаты, писем и поддержки.
• Shipping address совпадает с тем, что подтвердил клиент.
• Все позиции, вариации и add-on данные видны в заказе.
• Купон, ручная цена, fee и доставка отражены в итогах и заметках.
• Налоги пересчитаны по адресу и настройкам магазина.
• Статус соответствует оплате: ожидание, удержание, обработка или завершение.
• Письмо клиенту отправлено только тогда, когда оно действительно нужно.
• Внешние интеграции получили заказ без пропущенных полей.

Если клиент должен оплатить заказ по ссылке, проверьте её в правильной роли. Для заказа, привязанного к аккаунту, тестируйте вход под этим клиентом. Для гостевого заказа используйте тот же billing email. Если администратор видит ошибку доступа, сначала проверьте ownership заказа, а не отключайте платёжный шлюз.

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

Роли менеджеров, права доступа и операционная дисциплина

У ручных заказов есть особенность, которую часто недооценивают: заказ создаёт не покупатель, а сотрудник магазина. Это меняет распределение ответственности. В обычном checkout клиент сам вводит адрес, выбирает товар, подтверждает оплату и получает письмо. В phone order workflow менеджер становится человеком, который переносит волю клиента в систему. Поэтому права доступа и регламент здесь так же важны, как удобная форма.

Не стоит давать всем операторам роль администратора только потому, что так проще открыть нужный экран. Администратор может менять плагины, темы, настройки сайта и пользователей. Для приёма заказов обычно достаточно роли, которая умеет читать товары, создавать и редактировать заказы, видеть клиентов и работать с WooCommerce. Если стандартной роли Shop manager хватает, используйте её. Если не хватает, расширяйте права точечно и документируйте, зачем добавлена каждая capability.

Разделение задач между менеджером, складом и администратором

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

Для phone orders полезно вести короткий журнал спорных случаев. Не отдельную таблицу всех заказов, а именно список ситуаций, где менеджеру пришлось отступить от стандартного сценария: ручная цена, нестандартная доставка, товар вне каталога, заказ без email, отмена после оплаты, повтор заказа с заменой вариации. Раз в неделю этот список стоит просматривать администратору магазина. Если одна и та же ситуация повторяется, её лучше превратить в настройку, товар, шаблон fee или инструкцию.

Минимальный регламент для операторов

Регламент не должен быть длинным документом, который никто не читает. Достаточно одной страницы с последовательностью действий и правилами исключений. Включите туда:

• Какие данные клиента обязательны до сохранения заказа.
• Когда использовать существующий аккаунт, а когда гостевой заказ.
• Как проверять SKU, вариацию и add-on данные перед подтверждением.
• Кто имеет право применять ручную цену, купон или fee.
• Какой статус ставить при оплате ссылкой, офлайн-оплате и подтверждённой оплате.
• Какие данные запрещено записывать в order notes.
• Когда заказ можно завершить сразу, а когда нужно оставить на удержании.

После внедрения плагина проведите короткую тренировку на staging. Дайте менеджерам три сценария: простой заказ, повторный заказ с заменой товара и заказ с проблемной доставкой. Пусть каждый сотрудник сохранит тестовый заказ и сам проверит его в WooCommerce > Orders. Такая тренировка быстро показывает, где интерфейс понятен, а где нужна внутренняя подсказка.

Интеграции с оплатой, складом, письмами и аналитикой

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

Платёжные шлюзы и order notes

Страница IgniteWoo заявляет работу с большим числом payment gateways, включая распространённые офлайн и онлайн-решения. Но сама фраза "works with most payment gateways" не означает, что каждый шлюз одинаково обрабатывает ручной заказ, оплату по ссылке, virtual terminal, сохранённые карты или MOTO-сценарий. Проверяйте каждый способ оплаты отдельно.

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

Склад и остатки

WooCommerce status flow влияет на остатки. В зависимости от статуса и настроек склада заказ может уменьшать stock или ждать оплаты. Если магазин продаёт ограниченный товар по телефону и через сайт одновременно, важно понимать, когда именно резервируется остаток. Для стрессовых сценариев, например распродажа или приём заказов несколькими операторами, создайте тест с двумя менеджерами и одним товаром с малым остатком. Это покажет, нет ли риска принять больше заказов, чем магазин может выполнить.

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

Письма и ожидания клиента

Для клиента ручной заказ должен выглядеть предсказуемо. Он не обязан понимать, что заказ ввёл оператор. Он должен получить понятное письмо, корректную сумму, способ оплаты или информацию о следующем шаге. Если магазин отправляет order details email вручную, проверьте шаблон письма и дополнительный текст. В нём не должно быть внутренних пометок менеджера, но должны быть условия оплаты, доставка и контакт для вопросов.

Если клиент сообщает, что письмо не пришло, не создавайте новый заказ сразу. Сначала проверьте billing email, журнал отправки, order notes и статус. Повторное создание заказа ради письма часто приводит к дублям, неверным остаткам и путанице в аналитике. Лучше исправить email и повторно отправить order details из карточки заказа, если это соответствует вашему процессу.

Аналитика, CRM и внешние системы

Многие магазины отправляют заказы в CRM, бухгалтерию, сервис доставки, email marketing или BI-отчёты. Такие интеграции часто фильтруют заказы по статусу, payment method, source, user role или custom meta. После внедрения phone order workflow проверьте, как ручной заказ виден во внешних системах. Если CRM не отличает телефонный заказ от обычного, это может быть нормально. Если отделу продаж нужно видеть канал, добавьте безопасную внутреннюю метку через поддерживаемое поле или заметку, а не через правку кода плагина.

Отдельно проверьте отмены и возвраты. Телефонный заказ может отмениться до оплаты, после оплаты или после частичной сборки. Для каждого случая нужен понятный статус и действие: Cancelled, Failed, Refunded или внутренняя стадия, если магазин использует отдельный status manager. Не используйте статус Completed как универсальный "разобрались", потому что он означает выполненный заказ и может запускать интеграции.

Практический пример: заказ постоянного клиента с вариацией, купоном и доставкой

Разберём сценарий, который действительно проверяет пользу WooCommerce Phone Orders & Manual Orders. Клиент звонит в магазин и хочет повторить прошлую закупку, но заменить одну вариацию, применить действующий купон и отправить заказ на новый адрес. Менеджер должен оформить заказ во время разговора, не потеряв налоги, доставку и историю клиента.

Цель

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

Подготовка

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

Шаги

1. Откройте интерфейс ручного заказа и найдите существующего клиента по email или имени.
2. Загрузите прошлый заказ как основу, если такая функция доступна в текущей версии и подходит сценарию.
3. Удалите позицию, которую клиент больше не покупает, и добавьте новую вариацию по SKU.
4. Проверьте количество, add-on поля и любые комментарии к товару.
5. Введите новый shipping address и пересчитайте доставку.
6. Примените купон и убедитесь, что скидка появилась в итогах.
7. Выберите способ оплаты: ссылка клиенту, офлайн-оплата или разрешённый провайдером телефонный сценарий.
8. Сохраните заказ и откройте его в WooCommerce > Orders.

Проверка

В карточке заказа должны быть видны правильный клиент, новый адрес, актуальные позиции, вариация, купон, доставка, налоги и заметка, объясняющая ручную корректировку, если она была. Если заказ отправляется на оплату, проверьте письмо и payment link. Если оплата уже подтверждена, проверьте статус и order notes.

Нюанс

Самая частая ошибка в таком сценарии - менеджер копирует прошлый заказ и забывает пересчитать условия. Цены, налоги, доставка, остатки и купоны могли измениться. Поэтому копия - это быстрый черновик, а не готовый заказ. Второй риск - привязка заказа к аккаунту, когда оплату по ссылке будет открывать другой человек. В таком случае заранее решите, нужен ли заказ с аккаунтом или гостевой сценарий.

Частые проблемы и диагностика ручных заказов

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

Товар или вариация не находится через поиск

Симптом: менеджер вводит название или SKU, но нужная позиция не появляется. Возможная причина: SKU не заполнен у вариации, товар скрыт, отключён, не опубликован, конфликтует плагин поиска или сложный тип товара требует отдельной совместимости. Что проверить: карточку товара, SKU вариации, статус публикации, наличие товара в каталоге и работу поиска при отключённых необязательных админ-скриптах на staging. Как исправить: привести SKU в порядок, обновить индексацию стороннего поиска, протестировать без конфликтующего расширения, уточнить у разработчика поддержку конкретного product type. Если товар критичен и не поддерживается, откатите использование плагина для этого сценария до подтверждения совместимости.

Доставка не пересчитывается или показывает неверный тариф

Симптом: заказ сохранён, но доставка отсутствует, слишком низкая или не соответствует зоне. Возможная причина: не введён полный адрес, зона доставки не покрывает регион, carrier API недоступен, вес или габариты товара не заполнены, менеджер применил custom shipping price без основания. Что проверить: shipping zones, адрес, вес, методы доставки, журналы shipping-плагина и итог заказа после пересчёта. Как исправить: дополнить адрес, исправить зону, повторить расчёт, временно использовать ручную доставку только с заметкой. Если автоматический метод нестабилен, лучше вернуть заказ на удержание и подтвердить стоимость, чем отправить клиенту неверный итог.

Клиент не может оплатить ссылку

Симптом: клиент открывает payment link и видит отказ или не попадает на оплату. Возможная причина: заказ привязан к аккаунту, а клиент не вошёл под нужным пользователем; администратор тестирует ссылку от своего имени; гостевой заказ требует подтверждения billing email; платёжный шлюз не поддерживает выбранный сценарий. Что проверить: customer field в заказе, billing email, статус заказа, способ оплаты, order notes и документацию шлюза. Как исправить: попросить клиента войти в нужный аккаунт, создать гостевой заказ для разового платежа, отправить новое письмо с корректной ссылкой или выбрать другой разрешённый способ оплаты. Не отключайте защиту доступа ради удобства.

Заказ зависает в статусе On hold или Pending payment

Симптом: заказ создан, но склад не приступает к обработке или менеджер ждёт автоматического перехода. Возможная причина: выбран офлайн-метод, оплата не подтверждена, gateway ждёт уведомление, заказ создан как ожидающий оплаты. WooCommerce считает такие статусы нормальной частью потока. Что проверить: способ оплаты, транзакцию у провайдера, заметки заказа, настройки писем и expected status flow. Как исправить: после подтверждения оплаты вручную перевести заказ в Processing или другой рабочий статус магазина. Если статусы меняются автоматически неверно, тестируйте на staging с минимальным набором плагинов.

Итоги заказа отличаются от ожидаемых после копирования

Симптом: повторный заказ имеет неверный налог, скидку, цену или доставку. Возможная причина: копия подтянула старые данные, изменилась настройка отображения цен с налогом, истёк купон, поменялись тарифы или включился другой pricing plugin. Что проверить: текущие цены каталога, tax display setting, купон, shipping method, changelog плагина и правила скидок. Как исправить: пересчитать заказ, заново применить купон, проверить адрес и заменить устаревшие позиции. Если ошибка появилась после обновления, временно откатите процесс к стандартному ручному созданию заказа на staging и передайте точный сценарий разработчику.

Письма уходят не тому человеку или не уходят вовсе

Симптом: клиент не получил письмо, получил письмо с неполными данными или письмо ушло менеджеру. Возможная причина: неверный billing email, выключенное письмо, ручное order details email не отправлено, SMTP-проблема, статус не запускает нужное уведомление. Что проверить: billing email, WooCommerce email settings, журнал SMTP, order notes и статус. Как исправить: исправить email, повторно отправить order details, проверить шаблоны писем и не менять статус туда-сюда без понимания, какие уведомления это запустит.

Безопасные улучшения процесса без рискованного кода

Для этого продукта не стоит добавлять случайные PHP-snippets: публичная документация IgniteWoo не даёт набора официальных хуков для кастомизации интерфейса, а вмешательство в создание заказов, оплату и статусы без подтверждённого API может сломать данные. Вместо кода лучше улучшить процесс организационно и через штатные настройки WooCommerce.

Сделайте короткий внутренний регламент для менеджеров. Он должен включать порядок вопросов клиенту, правила выбора guest/account, условия ручной цены, обязательные заметки, запрет на хранение чувствительных платёжных данных, контроль статуса и проверку в WooCommerce > Orders. Такой документ часто снижает ошибки сильнее, чем кастомный код.

Второе улучшение - создать тестовый набор товаров. В него стоит включить простой товар, вариацию, товар с add-on, товар с весом для доставки, товар со скидкой и товар, который часто повторяют B2B-клиенты. После каждого обновления WooCommerce, плагина или платёжного расширения прогоняйте этот набор на staging.

Третье улучшение - договориться о заметках заказа. Например: если менеджер меняет цену, он пишет "Ручная цена согласована с клиентом по телефону"; если добавляет fee, пишет основание; если использует custom shipping price, указывает источник расчёта. Это не требует кода и помогает поддержке, складу и бухгалтерии.

Когда стоит использовать WooCommerce Phone Orders & Manual Orders

WooCommerce Phone Orders & Manual Orders будет удачным выбором, если ручные и телефонные заказы для вас не исключение, а часть продаж. Его сильная сторона - собрать заказ внутри WooCommerce быстро и достаточно полно: клиент, товары, SKU, сложные product types, доставка, оплата, купон, fee, ручная цена, удержание, повтор прошлого заказа и сохранение результата в обычной системе заказов.

Перед запуском на рабочем сайте проведите проверку на staging, особенно если используете HPOS, сложные товары, внешние службы доставки, tax-сервисы, payment gateways, wholesale pricing или sequential order numbers. Не принимайте первый реальный звонок как тест. Тест должен быть завершён заранее и включать проверку письма, статуса, payment link, остатков, налогов и интеграций.

Если после чтения вы понимаете, что плагин закрывает именно ваш сценарий - телефонные продажи, повторные B2B-заказы, заказы из офлайн-точки или ручное оформление сложных товаров - можно получить версию для WordPress и затем проверять его на копии магазина. Если же задача состоит в публичной фронтенд-форме заказа или в минимальном ручном вводе раз в несколько месяцев, сначала сравните его со стандартным WooCommerce и альтернативами из раздела выше.