Що насправді робить розробку e-commerce дорогою

Peretz Group

Chapters

What Actually Makes E-Commerce Development Expensive

Власник бізнесу запитує три агенції, скільки коштує побудувати інтернет-магазин.

Відповіді приходять: $18 000, $65 000 і $190 000.

Той самий бриф. Ті самі фотографії товарів. Та сама дата запуску.

Природна реакція, припустити, що хтось завищує, або що хтось інший просто знайшов розумніший спосіб побудувати.

Зазвичай ні те, ні інше.

Три агенції можуть просто оцінювати три різні продукти.

Ззовні інтернет-магазин може виглядати оманливо просто. Головна, сторінки товарів, кошик, оформлення замовлення і кнопка оплати.

Але видима вітрина, це лише один шар.

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

Вітрина і комерційна система можуть виглядати майже однаково ззовні.

Ми будували і те, і інше.

Ось що реально рухає цифру.

SKU обманює

Перше питання в більшості e-commerce брифів звучить так:

Скільки у вас товарів?

Звучить як важливе число.

Часто це не так.

Каталог із 5000 простих товарів, у кожного одна ціна, один залишок і кілька зображень, це по суті плаский набір даних.

Імпортувати його довше, ніж 500 товарів.

Але система під ним може бути відносно простою.

Тепер візьмемо 500 товарів, де кожен може відрізнятись розміром, кольором, матеріалом і оздобленням.

Ці 500 товарів можуть породжувати десятки тисяч реальних комбінацій. І кожній комбінації може знадобитись своя ціна, свій стан залишку, своє зображення, своя доступність і своє місце в пошуку та фільтрах.

Це не просто каталог більший.

Це інша модель даних.

Цю різницю легко упустити, бо бізнес природно описує свій магазин у термінах товарів.

Розробникам доводиться думати в термінах зв'язків.

Що змінюється, коли клієнт обирає інший матеріал?

Чи змінюється ціна?

Чи змінюється залишок?

Чи змінюється зображення?

Чи можна взагалі замовити цю комбінацію?

Чи має вона з'являтись у пошуку?

Чи може клієнт її повернути?

Що відбувається, якщо обрана комбінація тимчасово недоступна?

Кількість товарів каже, скільки інформації існує.

Вона на диво мало каже про те, що система має з цією інформацією робити.

Робочий приклад: SHTAYER, бренд преміального домашнього текстилю. Каталог не величезний, але майже кожен товар несе логіку розміру і матеріалу, і ці атрибути впливають на ціну, доступність і на те, як клієнт звужує пошук. Платформа, на якій магазин спочатку запустився, у якийсь момент вичерпала місце для цієї логіки, тому зараз магазин переїжджає на кастомну збірку на Laravel. Каталог не став більшим. Він став структурнішим. Проєкт можна подивитись у нашому портфоліо, а про рішення, що стоїть за таким переїздом, ми писали у статті Коли бізнес переростає WordPress?

Варіації, множник

Щойно з'являються варіації, кілька систем мають узгоджуватись одна з одною.

Ціноутворення має знати, що один матеріал коштує дорожче за інший.

Облік залишків має відстежувати правильну комбінацію.

Пошук і фільтри мають уникати показу комбінацій, яких не існує.

Фотографія має представити достатньо варіацій, щоб допомогти клієнту, але не вимагати окремого знімка для кожної можливої комбінації.

А CMS має дозволяти людині на боці клієнта керувати всім цим, не зламавши каталог випадково.

Ми бачимо це особливо ясно в категоріях, з якими працюємо.

Преміальний домашній текстиль може нести логіку розміру і матеріалу.

Ювелірка може нести метал, камінь, розмір і персоналізацію.

Меблі можуть нести габарити, оздоблення, конфігурації і терміни виготовлення.

Жоден із цих бізнесів не обов'язково вважає себе технічно складним.

Складні їхні каталоги.

Тут же B2B e-commerce стає іншим завданням.

Персональні ціни, обсягові знижки і контрактні ставки, це не просто ще одне поле в картці товару. Вони перетворюють ціноутворення на систему, яка має розуміти, хто клієнт і які комерційні правила до нього застосовуються.

Каталог перестає бути списком.

Він стає інфраструктурою.

Чого клієнт не бачить

Бриф зазвичай описує те, що бачить клієнт.

Вартість часто живе в тому, що бізнес обслуговує за цим.

ERP.

Бухгалтерія.

CRM.

Складський облік.

Залишки.

Доставка.

Платіжні шлюзи.

Email-автоматизація.

Податкові сервіси.

Питання не просто в тому, чи потрібно цим системам з'єднатись.

Питання в тому, як вони мають поводитись, коли щось іде не так.

Одностороння інтеграція може бути фідом.

Двостороння інтеграція, це контракт між двома системами, кожна з яких вважає себе правою.

Якщо падає фід, інформація може застаріти.

Якщо падає двостороння інтеграція, наслідки можуть бути куди серйознішими: залишки можуть стати неточними, замовлення можуть задвоїтись, а рахунок може не збігтись із тим, що реально відвантажили.

Тому нормальна інтеграція вимагає більшого, ніж перенесення даних з А до Б.

Вона вимагає обробки конфліктів, повторних спроб, збоїв і звірки. Це інженерна робота, навіть якщо нічого з неї не з'являється в дизайн-макеті.

Для американського бізнесу податок з продажів додає ще один невидимий шар.

Ставки можуть різнитись за штатами, округами і містами, а класифікація товару може впливати на сам розрахунок.

Клієнт бачить підсумкову суму в кошику.

За нею можуть стояти податковий сервіс, класифікації товарів і логіка, яка має лишатись коректною, поки замовлення рухається через систему.

Клієнт бачить кнопку. Бізнес бачить ланцюг систем, які мають домовитись про те, що станеться після натискання.

Ціна зручності

Хостингові платформи мають величезний сенс для багатьох бізнесів.

Підписка і комісія з транзакції можуть бути значно вдалішим рішенням, ніж витрачатись на інфраструктуру, яка бізнесу насправді не потрібна.

Ми рекомендуємо такий підхід, коли він підходить бізнесу.

Проблема починається, коли вибір платформи стає ідеологією.

На малих обсягах відсоток із кожної транзакції може бути незначним.

На суттєвих обсягах арифметика змінюється.

Бізнес з оборотом $5 мільйонів на рік може платити тисячі доларів щорічно лише комісій; при $20 мільйонах регулярна вартість стає помітно відчутнішою. Точна цифра залежить від платформи, тарифу і платіжної структури, але суть проста: відсоток лишається відсотком у міру зростання виручки.

Це не означає, що кастомна розробка автоматично дешевша.

Це означає, що порівняння з часом змінюється з:

Яка платформа краща?

на:

У який момент регулярна вартість зручності перевищує вартість володіння?

Ця точка різна для кожного бізнесу.

Ширше питання build-versus-buy ми розбираємо у статті Рівняння «будувати чи купувати» змінилось.

Розробка і магазин

Один із найлегших способів зробити e-commerce пропозицію вигідною на вигляд, це оцінити видиму розробку і лишити операційну роботу на потім.

Дані про товари може знадобитись перенести, вичистити і переструктурувати, бо старий каталог будувався навколо іншої моделі.

Наявні URL може знадобитись зіставити і перенаправити, щоб бізнес не втратив пошукову видимість, накопичену за роки.

Аналітику і e-commerce трекінг потрібно налаштувати коректно.

Платежі і розрахунок податків потрібно протестувати на реальних транзакціях.

Когось на боці клієнта потрібно навчити працювати із системою.

Нічого з цього не робить особливо вражаючий слайд у презентації.

Усе це визначає, чи працює магазин насправді.

Саме тому ми розрізняємо запуск сайту і запуск бізнес-системи.

Магазин, що виходить у життя без підготовлених даних, трекінгу, платіжної логіки, міграції і операційних процесів, не закінчений.

Він просто видимий.

Те саме стосується термінів.

Відносно простий магазин на темі може запуститись за тижні.

Кастомна комерційна система з реальними інтеграціями може зайняти кілька місяців.

Але навіть ці діапазони приховують ще одну змінну: наскільки стабільні вимоги?

Припущення, що вимоги лишаться незмінними, одне з найлегших для ухвалення і одне з найважчих для утримання.

Витрати після запуску

E-commerce ближчий до експлуатації системи, ніж до володіння сайтом.

Є хостинг.

Безпека.

Оновлення.

Моніторинг.

Виправлення помилок.

Сторонні сервіси.

Застосунки.

API-залежності.

Зміни платформи.

І з часом нові вимоги.

Тому корисна модель планування враховує вартість експлуатації системи після запуску, а не лише початковий бюджет розробки. Поширений орієнтир, приблизно 10-20% від вартості первинної збірки щорічно, що покривають хостинг, безпеку, оновлення, моніторинг і виправлення, тоді як хостингові платформи розподіляють ці витрати інакше, через підписки і застосунки.

Психологія регулярних витрат цікава.

Одне інженерне рішення за $20 000 відчувається великим.

П'ятнадцять застосунків по $50 на місяць ні.

Поки їх не стане п'ятнадцять.

І кожен застосунок, це ще й залежність.

Він може змінити ціну.

Він може перестати підтримуватись.

Він може конфліктувати з іншим застосунком.

Він може зламатись після оновлення платформи.

Саме тому дешево запустити і дешево володіти, це різні питання.

Розкид удесятеро

Тепер початкове питання про $18 000 проти $65 000 проти $190 000 стає зрозумілішим.

Іноді низький кошторис просто помилковий.

Іноді високий кошторис завищений.

Але часто різниця значно конкретніша.

Низький кошторис може рахувати вітрину.

Високий кошторис може рахувати систему під нею.

Одна агенція може припускати прості товари, мінімум інтеграцій і чисту міграцію.

Інша могла запитати, що відбувається, коли:

у клієнта контрактні ціни
залишки змінюються на складі
у товару десятки комбінацій
потрібно порахувати податок
замовлення має пройти через кілька систем
наявні URL мають пережити міграцію
бізнесу потрібна надійна звітність після запуску

Це не абстрактні відмінності.

Це рядки кошторису.

Важливо те, що багато з них можна виключити з пропозиції так, що пропозиція не виглядатиме неповною.

Саме тому discovery такий важливий.

Кошторис надійний рівно настільки, наскільки хороші питання, поставлені до нього.

І є відмінність, яку варто проговорити дуже ясно:

Дешевий кошторис не обов'язково поганий кошторис. Дорогий кошторис не обов'язково хороший.

Простий бізнес не має платити за складність, яка йому не потрібна.

Складний бізнес, однак, має насторожитись від кошторису, що якимось чином спромігся не оцінити вже наявну в нього складність.

Обдумані покупки

Є ще одна змінна, що мало пов'язана з розміром каталогу.

Як клієнт ухвалює рішення?

Одні товари купують майже одразу.

Інші обдумують днями, тижнями чи місяцями.

Клієнту, що купує знайомий недорогий товар, зазвичай корисний найкоротший надійний шлях до оформлення.

Тому, хто розглядає прикрасу, комплект преміального текстилю чи предмет меблів, що може простояти в нього вдома двадцять років, можуть знадобитись провенанс, характеристики, матеріали, детальна фотографія, порівняння, підтвердження і іноді розмова перед покупкою.

Це не просто додаткові сторінки.

Це інша архітектура.

Це важливо, бо поради з e-commerce часто подають так, ніби оптимізація конверсії універсальна.

Знижуй тертя.

Скорочуй шлях.

Прибирай відволікання.

Роби оформлення швидшим.

Часто це хороші принципи.

Але клієнт, що купує обдумано, не обов'язково хоче найкоротший шлях.

Йому може бути потрібна інформація, що робить наступний крок комфортним.

Саме тому ювелірний магазин, бренд преміального текстилю і роздріб повсякденних товарів можуть усі бути успішними e-commerce бізнесами, вимагаючи при цьому зовсім різного цифрового досвіду.

Ми розбирали це у статтях Чому luxury e-commerce порушує всі правила conversion optimization і Як ми проєктуємо e-commerce: від об'єктів до досвіду.

Оцінювати магазин обдуманої покупки так, ніби це магазин повсякденних товарів, одна з найдорожчих доступних помилок.

Робочий приклад: Magerit, іспанський ювелірний дім, чиї вироби організовані не лише за товарними категоріями, а й за колекціями, побудованими навколо міфології, природи і чотирьох стихій. Це дає клієнту два законні входи: через продукт або через історію. Інтерфейс мав підтримати обидва, плюс окремий розділ дитячих прикрас, де покупець, мова і процес ухвалення рішення зовсім інші. Нічого з цього не проблема розміру каталогу. Це проблема архітектури. Кейс є в нашому портфоліо.

Географія і витрати

Ставки розробки суттєво різняться за географією.

Це законний фактор при порівнянні пропозицій.

Але погодинна ставка, це не те саме, що цінність проєкту.

Нижча ставка не означає автоматично нижчу компетентність.

Вища ставка не означає автоматично кращу інженерію.

Корисніше питання звучить так:

Що саме я отримую за цю ставку?

Скільки discovery?

Яку архітектуру?

Які інтеграції?

Яку міграцію даних?

Яке QA?

Що відбувається після запуску?

Що відбувається, коли вимоги стають конкретнішими?

Наші інженерні команди перебувають у Європі, що дає нам іншу структуру витрат, ніж у багатьох американських агенцій. Це може дозволити більшій частці бюджету піти в інженерію, інтеграції, архітектуру даних і стабільність після запуску, а не в базу витрат навколо доставки проєкту.

Ми не подаємо це як знижку.

Суть просто в тому, що структура витрат і якість, це не та сама змінна.

І географія не вирішує фундаментальну проблему.

Команда в будь-якій точці світу може дуже ефективно побудувати не ту систему.

Захист від цього, discovery і архітектура.

Команда може бути недорогою і все одно побудувати не те. Команда може бути дорогою і все одно побудувати не те.

Важлива частина, зрозуміти бізнес до того, як відкрили редактор коду.

Що запитати першим

Перш ніж порівнювати e-commerce пропозиції, постав питання, що розкривають припущення за цифрою.

Товари прості чи конфігуровані? Хто визначив модель даних товару?
Які інтеграції включені? Вони односторонні чи двосторонні?
Як обробляється податок з продажів?
Чи включена міграція даних про товари? Чи включає вона чистку і переструктурування?
Чи включена SEO-міграція? Хто складає і перевіряє карту редиректів?
Яка аналітика і e-commerce трекінг включені?
У що реально обійдеться перший рік володіння? Включно з хостингом, застосунками, ліцензіями і сторонніми сервісами.
Що відбувається в перші вісім тижнів після запуску?

І, мабуть, найпоказовіше питання:

Які припущення ви зробили, щоб дійти до цієї ціни?

Агенція, що може відповісти на ці питання ясно, ймовірно, думала про проєкт.

Агенція, що не може, можливо, просто оцінює припущення.

Справжня ціна e-commerce

Розробка e-commerce стає дорогою, коли складний бізнес за магазином.

Не обов'язково тому, що в нього тисячі товарів.

Тому що ці товари поводяться по-різному.

Тому що клієнти бачать різні ціни.

Тому що залишки живуть в іншому місці.

Тому що замовлення мають рухатись між системами.

Тому що потрібно рахувати податок.

Тому що наявні URL накопичили цінність.

Тому що клієнтам потрібно більше інформації перед покупкою.

Тому що бізнесу потрібно, щоб система продовжувала працювати після запуску.

І іноді тому, що бізнес переріс платформу, з якої починав.

Саме тому ми скептичні до універсальних прайс-листів на e-commerce.

Не існує осмисленої ціни на «інтернет-магазин» у відриві від контексту.

Є ціна конкретного каталогу, конкретної бізнес-моделі, конкретного клієнтського шляху і конкретного набору операційних вимог.

Тому правильне питання не:

Скільки коштує інтернет-магазин?

А:

Що наш бізнес реально вимагає від системи?

Щойно це зрозуміло, ціну стає набагато легше пояснити.

І набагато важче підробити.

Якщо ти плануєш e-commerce розробку і хочеш зрозуміти, що реально вимагають твій каталог, інтеграції, клієнтський шлях і операції, перш ніж порівнювати пропозиції, саме для цього і потрібна Стратегічна сесія.

Забронювати Стратегічну сесію

Ознайомтесь з нашими послугами розробки e-commerce.