Як агентствам варто думати про криптоплатежі
Агентства не виставляють рахунки так само, як магазини. Студія вебдизайну може взяти 50% передплати в понеділок, призупинити роботу в середу через фідбек клієнта й надіслати рахунок за етап у п’ятницю. Команда SEO на ретейнері може виставляти інвойс першого числа, а потім додавати термінову плату за аудит 18-го. Це різні платіжні події, і криптовалютні платежі для агентства мають підходити до кожної з них.
Помилка — ставитися до кожного рахунку однаково. Один клієнт може хотіти щомісячний ретейнер у USDC. Інший — заплатити за разовий рекламний проєкт у BTC. Третій може попросити розділити рахунок, бо внутрішнє погодження відбувається у два етапи. Якщо ваше агентство обробляє все це через один checkout, хтось кілька днів буде розгрібати ланцюжок листів.
Не існує єдиного платіжного сценарію для агентств. У цьому й суть.
Чому агентствам потрібне окреме налаштування криптоплатежів
Ретейнери, передплати, етапні рахунки та білінг по клієнтах створюють чотири окремі правила. Ретейнер може бути регулярним, але зазвичай це не підписка в програмному сенсі. Передплата може бронювати виробничий слот. Рахунок за етап може залежати від погодження креативного директора, а не від календарної дати. Білінг по клієнтах додає ще один рівень, бо два акаунти можуть належати одній материнській компанії, але все одно потребувати окремих номерів інвойсів.
Саме тому питання, як приймати криптоплатежі для агентств, — це не лише про checkout. Це ще й про робочий процес. Агентству потрібно знати, хто створює інвойс, який гаманець або платіжне посилання використовується, чи платіж стосується Проєкту A чи Проєкту B, і коли починається виконання. Коротка затримка тут може означати, що дизайнер уже починає роботу, а фінанси ще не бачили оплату.
Один практичний приклад: брендингова агенція бере 30% передплати за новий айдентику-пакет, потім виставляє рахунок на 40% після погодження концепції та решту 30% після фінальних файлів. Якщо в позначках інвойсу не розділити ці три етапи, фінансова команда може занадто рано відмітити весь проєкт як оплачений. Потім це створює незручні дзвінки.
Вирішіть, за які послуги агентства ви прийматимете крипту
Не кожна послуга підходить для крипти. Почніть із робіт, які найлегше пояснити та найпростіше відстежувати. Міжнародні клієнти — очевидна перша група, особливо коли банківські перекази повільні або дорогі. Разові проєкти теж добре підходять, бо платіж прив’язаний до одного обсягу робіт. Термінові роботи також доречні, адже клієнт у дедлайні зазвичай віддає перевагу швидкому шляху оплати.
Деякі агентства залишають крипту лише для клієнтів поза своїм домашнім ринком. Інші приймають її тільки для ретейнерів вище певного внутрішнього порогу. Практичний фільтр такий: якщо послуга вже має чіткий номер інвойсу, зрозумілу дату здачі та названого погоджувача з боку клієнта, вона кращий кандидат, ніж розмитий “support bucket”.
Термінова робота потребує окремого підходу. Виправлення сайту за 24 години або правка лендингу в той же день рухається швидко, і клієнтам не хочеться довгого процесу оплати перед стартом робіт. Крипта може допомогти, але лише якщо агентство тримає пропозицію вузькою. “Emergency fix” — нормально. “Щось термінове” — ні.
Якщо ваше агентство також працює з софтверними клієнтами, вам може бути корисно порівняти цю модель із криптовалютним платіжним шлюзом для SaaS, перш ніж вирішити, які пропозиції мають бути в одному процесі.
Встановіть умови криптоплатежів для клієнтських контрактів і пропозицій
Кожна пропозиція має відповідати на п’ять питань: валюта ціни, строк дії комерційної пропозиції, мережеві комісії, правила повернення коштів і коли платіж вважається отриманим. Якщо хоча б одного пункту немає, клієнт запитає пізніше, а відповідь зазвичай з’являється вже після того, як рахунок надіслано. Це можна уникнути.
Оцінюйте роботи в одній базовій валюті, а потім вказуйте правило розрахунку суми в крипті в самій пропозиції. Якщо ваше агентство виставляє ціну в USD, але приймає крипту, поясніть, як фіксується курс і як довго діє пропозиція. Вікно дії 48 годин — поширена практика для динамічних проєктів, але цей термін має бути прописаний. Інакше клієнт може порівняти суму через два дні й заперечити.
Мережеві комісії треба описувати простою мовою. Вкажіть, чи клієнт сплачує комісію зверху, чи вона вже включена в кошторис, і що станеться, якщо надіслана сума буде меншою через комісії гаманця. Це звучить сухо. Але це економить суперечки.
Правила повернення коштів мають бути достатньо конкретними, щоб пережити спір. Якщо роботу ще не почали, чи може агентство повернути кошти в тій самій валюті? Якщо етап уже погоджено, чи є ця частина невідшкодовуваною? Внесіть правило в пропозицію, а не в повідомлення Slack. Хороший рядок у договорі кращий за довгий лист із вибаченнями.
Побудуйте простий робочий процес виставлення інвойсів для крипти
Робочий процес інвойсингу має бути нудним у найкращому сенсі. Спочатку створіть інвойс із назвою клієнта, назвою проєкту, періодом послуги та точною сумою оплати. Потім додайте правильну адресу гаманця або платіжне посилання. Далі прив’яжіть інвойс до одного коду проєкту у внутрішній системі. І насамкінець підтвердьте оплату, перш ніж хтось позначить роботу як відкриту до продакшену.
Коли клієнтів кілька, цей етап швидко стає хаотичним. Найкращий підхід — один ID інвойсу на один проєкт і одне платіжне призначення на один інвойс. Якщо фінансова команда повторно використовує гаманець без обліку, звірка перетворюється на вгадування. Один пропущений референс може змусити когось потім шукати транзакцію вручну.
Багато агентств для невеликого обсягу ведуть спільну таблицю, а коли активних клієнтів стає більше, переходять на платіжну платформу. Це нормально. Важливо, щоб у таблиці було щонайменше чотири поля: номер інвойсу, клієнт, сума і статус. На старті достатньо статусів: оплачено, очікує, прострочено, частково оплачено.
Якщо вашій команді потрібен технічний орієнтир, дивіться документацію для розробників, API криптоплатіжного шлюзу щодо API-орієнтованих процесів і деталей обробки інвойсів.
Узгодьте погодження між продажами, фінансами та виконанням
Агентства втрачають час, коли три команди припускають, що хтось інший перевіряє оплату. Продажі закривають угоду. Фінанси виставляють рахунок. Команда виконання хоче почати роботу. Якщо ці ролі не прописані, дизайнер може почати роботу до підтвердження оплати, або фінанси можуть притримати інвойс, бо продажі пообіцяли знижку, яку ніхто не зафіксував.
Простіший процес передачі працює краще, ніж неформальний чат. Продажі мають підтвердити обсяг і ціну. Фінанси — виставити інвойс і стежити за статусом оплати. Команда виконання — чекати підтвердження платежу перед тим, як віддавати фінальні файли або запускати наступний етап. Якщо в малому агентстві одна людина поєднує дві ролі, це теж слід прописати. Не покладайтеся на пам’ять.
Корисне внутрішнє правило — “без підтвердження не віддавати”. Якщо платіж у процесі, жодні фінальні матеріали не виходять із агентства. Якщо оплата часткова, починається лише погоджений етап. Це захищає обидві сторони.
Деякі агентства додають червоний прапорець для термінових робіт: жодне завдання в той самий день не стартує, доки фінанси не побачать хеш транзакції або підтвердження платіжного посилання. Звучить жорстко. Але це запобігає безкоштовній роботі.
Обробляйте ретейнери, етапи та часткові платежі
Ретейнери слід трактувати як постійний доступ, а не як чистий чек. Якщо агентство виставляє щомісячний ретейнер, визначте, що саме він покриває: години, час відповіді, правки чи конкретний список послуг. Без цього клієнт може вирішити, що ретейнер покриває дзвінки у вихідні, ще три лендинги й редизайн бренду. Це не так.
Для етапної роботи розбийте проєкт на 2 або 3 платіжні стадії. Поширена схема — передплата, середній платіж і фінальний баланс. Клієнт бачить прогрес. Агентство бачить грошовий потік. І ніхто не мусить здогадуватися, що означає “майже готово”.
Часткові платежі потребують видимих позначок. Якщо клієнт платить 60% зараз і 40% пізніше, інвойс має показувати залишок і умову для наступного платежу. Ніколи не ховайте баланс у довгій примітці. Виносьте його в тіло інвойсу та в контракт.
Ось чітка послідовність:
- Надішліть інвойс на передплату із датою старту.
- Дочекайтеся підтвердженої оплати.
- Починайте перший результат лише після підтвердження.
- Виставляйте інвойс за етап, коли досягнуто погодженої контрольної точки.
- Позначайте фінальний баланс до сплати перед передачею фінальних файлів.
Такий порядок допомагає клієнту не відчувати несподіванок. Він також допомагає агентству уникати безкоштовних правок після того, як фінальний баланс уже мав бути отриманий, але так і не надійшов.
Звіряйте криптоплатежі з вашою бухгалтерською системою
Бухгалтерський облік має збігатися інвойс за інвойсом. Фіксуйте дату, отриманий актив, номер інвойсу, назву клієнта та референс транзакції. Якщо ваша облікова система погано зберігає деталі криптотранзакцій, ведіть паралельний запис, який це робить. І аудитори, і бухгалтери віддають перевагу прозорому сліду, а не розмитим спогадам.
Звіряти простіше, коли кожен інвойс має унікальний референс у призначенні платежу або в мітці отримувача. Якщо клієнт надсилає платіж без референсу, комусь доведеться гадати, до якого проєкту він належить. Саме такі дрібні помилки й перетворюються на хаос наприкінці місяця.
Деякі агентства роблять звірку наприкінці кожного тижня. Інші — щодня. Правильний вибір залежить від обсягу, але правило має залишатися тим самим: жоден інвойс не вважається “закритим”, доки вхідний платіж не зіставлено. Якщо платіж недоплачено хоча б на невелику суму, зафіксуйте це одразу. Не чекайте квартального перегляду.
Для агентств, які працюють із хостингом, інфраструктурою або технічними клієнтами, записи про оплату також мають містити чітке посилання на період послуги. Клієнт, який платить за підтримку в лютому, не має змішуватися з березневими роботами над сайтом. Це звучить очевидно, доки два проєкти не мають одного й того ж контактної особи.
Якщо вашій фінансовій команді потрібен точніший процес звірки, стаття про найкращі практики безпеки криптоплатіжних шлюзів буде корисним доповненням для роботи з записами та внутрішнім контролем доступу.
Створіть шаблон комунікації для клієнтів, які вперше платять криптою
Клієнтам, які вперше платять криптовалютою, потрібно менше слів, а не більше. Хороший шаблон пояснює чотири речі: який актив надсилати, куди надсилати, скільки надсилати і що буде після оплати. Цього достатньо для більшості клієнтів. Додаткові деталі краще винести в додаток, а не вставляти в перший лист.
Проста структура листа може виглядати так:
Тема: Інвойс і інструкції з оплати для проєкту X
Вітаємо, [Ім’я клієнта],
Дякуємо за підтвердження щодо проєкту X. У вкладенні — рахунок №104. Будь ласка, надішліть оплату в [назва активу] на адресу або за платіжним посиланням нижче. Вказана сума дійсна до [дата]. Після підтвердження платежу ми розпочнемо наступний етап і надішлемо перший результат до [дата].
Якщо хочете, ми також можемо підготувати другий інвойс для етапу після підтвердження цього платежу.
З повагою,
[Назва агентства]
Такий формат зменшує кількість уточнень, бо відповідає на два перші питання клієнтів: “скільки” і “що далі”. Коротка примітка про мережеві комісії теж допомагає. Якщо клієнт надішле не ту суму, відповідь має відсилати до умов інвойсу, а не починати довгі переговори.
Для міжнародних агентств у листі клієнту також можна зазначити, що підтвердження платежу може зайняти короткий час обробки залежно від мережі. Це робить очікування реалістичнішими. Клієнт, який очікує миттєвої передачі фінальних файлів, буде спокійнішим, якщо ви заздалегідь назвете цей крок.
Якщо ваше агентство також веде партнерські або реферальні програми, та сама дисципліна комунікації допомагає і в криптовиплатах для партнерів і рефералів, де інструкції з оплати мають бути короткими та точними.
І ще одна практична фраза має бути в кожному повідомленні для першого платежу: “Якщо ви не сплатите до дати завершення дії пропозиції, ми перевипустимо інвойс”. Це захищає агентство від застарілих курсів і не дає клієнту припустити, що стара сума все ще чинна.
Коментарі