Більшість матеріалів про інтернет-магазини закінчуються словами «і ось ви запустилися». Насправді на цьому найцікавіше тільки починається: змінюються версії PHP, партнери оновлюють API, каталог росте з 500 товарів до 6 000, а менеджери все ще ведуть замовлення в Excel.
Ця стаття — про те, що відбувається після запуску. Якщо ви тільки плануєте магазин, почніть із повного гайда з розробки на OpenCart або з порівняння платформ.
Чому OpenCart-магазин не буває «зробили і забули»
OpenCart — стабільна платформа, і в цьому пастка: магазин може роками працювати без явних поломок, поступово накопичуючи проблеми, які проявляться всі одразу.
- Оточення змінюється. Хостинг переходить на нову версію PHP — і половина модулів, написаних під 7.4, перестає працювати. Оновлення без підготовки перетворює магазин на білий екран.
- API партнерів версіонуються. Нова Пошта, платіжні шлюзи, маркетплейси змінюють формати й вимикають старі версії. Модуль, який ви поставили три роки тому, одного дня просто перестає створювати ТТН.
- Каталог росте. Те, що літало на 500 товарах, на 6 000 позицій з фільтрами починає віддавати категорію по 3–5 секунд.
- Безпека. OpenCart популярний, тому його масово сканують. Вразливість шукають не у вашому магазині особисто — її шукають у застарілому модулі, який стоїть у тисяч магазинів.
Що входить у підтримку
1. Оновлення й безпека
Головне джерело проблем — не ядро OpenCart, а сторонні модулі: саме там найчастіше знаходять SQL-ін'єкції та незахищене завантаження файлів. Що робимо:
- оновлюємо ядро й модулі з попередньою перевіркою на копії сайту, а не одразу на бойовому;
- прибираємо модулі, які більше не підтримуються автором, — або переписуємо їхню функцію під себе;
- переносимо адмінку з дефолтного шляху, вмикаємо двофакторну автентифікацію й обмеження за IP;
- перевіряємо каталоги завантажень на сторонні PHP-файли (класичний вебшел заїжджає саме через форму завантаження);
- тримаємо HTTPS і актуальні заголовки безпеки.
2. Бекапи, які справді відновлюються
Бекап, який жодного разу не розгортали, — це не бекап, а надія. Робочий мінімум: щоденний дамп бази й файлів, зберігання поза тим самим сервером, і раз на квартал — тестове відновлення на окремому домені. Це єдиний спосіб дізнатися, що архів не порожній, до того, як він знадобиться.
3. Швидкість
Швидкість каталогу — це гроші: на продажі вона впливає прямо. На великих каталогах найчастіше допомагають прості речі:
- індекси в таблицях
product_description,product_to_category,product_attribute— фільтри без них сканують усю таблицю; - кеш категорій і меню, щоб кожен перехід не перераховував дерево;
- зображення у WebP і lazy-loading — на картці товару з 15 фото це десятки мегабайтів різниці;
- вимкнення модулів, які лишилися «на майбутнє» і виконуються на кожній сторінці;
- чищення таблиць сесій і логів, які на живому магазині розростаються до гігабайтів.
4. Дрібні доробки й помилки
Це те, заради чого супровід і потрібен: додати поле в форму замовлення, поправити верстку акційного банера, змінити правила доставки перед святами. Окремо оцінювати кожну таку задачу довше, ніж її зробити, — тому вони закриваються в межах місячного пакета.
5. Моніторинг
Магазин має повідомляти про поломку раніше за клієнта. Мінімум, який варто тримати: аптайм, помилки створення замовлень, збої оплати, невдалі виклики до Нової Пошти й CRM. Окремо — журнал обміну з зовнішніми системами, без якого діагностика перетворюється на здогадки.
Коли магазину потрібна CRM
Адмінка OpenCart — це система керування замовленнями, а не відносинами з клієнтами. Вона не знає, що клієнту вже двічі дзвонили, не нагадає передзвонити через тиждень і не покаже, скільки замовлень зависло в обробці. Ознаки, що час рухатися далі (детальніше — у статті «Коли бізнесу потрібна CRM»):
- замовлення обробляють у пошті, Excel і Telegram одночасно;
- менеджер не памʼятає, що обіцяв клієнту минулого тижня, а історія листування — у нього в особистій скриньці;
- ніхто не може швидко сказати, скільки замовлень висить у статусі «в обробці» довше трьох днів;
- повторні продажі не робляться взагалі, бо база клієнтів існує лише як таблиця замовлень;
- залишки на сайті й на складі не сходяться, і про це дізнаються від клієнта.
Що синхронізувати між магазином і CRM
«Інтегрувати з CRM» — надто загально. На практиці це кілька окремих потоків даних, кожен зі своїм напрямком і частотою:
- Замовлення: OpenCart → CRM. Одразу після оформлення, разом із товарами, сумою, коментарем і UTM-міткою джерела.
- Статуси: у двох напрямках. Менеджер міняє статус у CRM — клієнт бачить його в магазині. Це найчастіше джерело плутанини, тому мапінг статусів має бути окремою таблицею відповідностей, а не зашитим у код.
- Клієнти: OpenCart → CRM з дедуплікацією за телефоном і email. Без неї база за пів року перетворюється на три картки одного покупця.
- Товари, ціни: облікова система або CRM → OpenCart. Ціни майже завжди ведуть в обліку, магазин їх лише відображає.
- Залишки: склад → OpenCart. Найкритичніший потік. Продати те, чого немає, коштує дорожче за будь-яку іншу помилку інтеграції.
- ТТН і оплати: CRM → OpenCart → клієнт. Номер накладної має доїжджати до покупця без участі менеджера.
Як це технічно робиться
Різниця між інтеграцією, яка працює роками, і тією, яку доводиться щотижня «підштовхувати», — у чотирьох речах.
- Черга замість прямого виклику. Якщо магазин звертається до CRM синхронно в момент оформлення, то падіння CRM = втрачене замовлення й помилка в клієнта на екрані. Правильно — покласти подію в чергу й віддати клієнту підтвердження одразу, а обмін виконати фоном із повторними спробами.
- Ідемпотентність. Кожне замовлення передається із зовнішнім ідентифікатором, і повторна відправка не створює дубль, а оновлює наявний запис. Без цього перша ж мережева помилка дає два однакові замовлення в CRM.
- Журнал обміну. Що відправили, коли, що відповіли, скільки було спроб. Це не «приємно мати» — без журналу питання «чому це замовлення не доїхало» не має відповіді.
- Планове вивантаження там, де воно доречне. Залишки й ціни не потребують реального часу: обмін кожні 5–15 хвилин навантажує систему в рази менше, ніж спроба синхронізувати кожну зміну.
Технічно обмін будуємо через REST API OpenCart або власний модуль, який віддає й приймає дані окремим захищеним ендпоінтом із токеном. Для складних випадків ставимо проміжний сервіс на Laravel: він тримає чергу, мапінг полів і журнал, а магазин і CRM про існування одне одного навіть не знають.
З якими системами інтегруємо найчастіше
- KeyCRM — популярна серед українського e-commerce, має нормальний API й готову роботу з Новою Поштою та касовими чеками. Найшвидший старт для магазину, який просто хоче вести замовлення по-людськи.
- Creatio — українська платформа рівня enterprise: угоди, контакти, воронка й процеси, коли компанія переросла просте ведення замовлень.
- OneBox — українська система, у якій CRM і облік живуть разом; зручна, коли не хочеться тримати дві окремі бази.
- Perfectum — українське рішення для сервісу й послуг, з можливістю розгортання на власному сервері.
- HubSpot, Pipedrive, Zoho — коли потрібна воронка продажів і робота менеджерів із заявками, а не облік.
- Українські облікові системи (Дебет Плюс, Master:Бухгалтерія, ISpro) — товари, ціни, залишки, накладні. Обмін зазвичай двосторонній і плановий, через проміжний сервіс.
- Галузеві рішення — за наявним API.
- Власна CRM на Laravel — коли готові системи не лягають на процес і доводиться підганяти бізнес під софт замість навпаки. Тоді інтеграція найпростіша: обидві сторони пишемо ми.
Функціонал, який реально потрібен магазину
Список того, що найчастіше доводиться доробляти вже після запуску. Якщо чогось із цього немає — це наступні задачі на супровід:
- пошук, який працює з друкарськими помилками й розкладкою, а не лише з точним збігом;
- фільтри за характеристиками (потужність, розмір, бренд), а не лише за категоріями;
- оформлення в один крок без обовʼязкової реєстрації;
- вибір відділення Нової Пошти з пошуком і автопідстановкою міста;
- онлайн-оплата разом із накладеним платежем — в Україні відмова від другого варіанта коштує частини замовлень;
- статус замовлення й номер ТТН, доступні клієнту без дзвінка менеджеру;
- сповіщення на кожній зміні статусу — email, SMS або Viber;
- вивантаження в маркетплейси (докладно — у статті про інтеграції OpenCart);
- GA4 з подіями електронної комерції, щоб рішення ухвалювалися за даними;
- адмінка, в якій менеджер працює швидко: масові дії, зрозумілі фільтри, імпорт цін.
Типові помилки
- Правки прямо в ядрі замість ocmod/vqmod. Магазин працює рівно до першого оновлення, після чого всі зміни зникають.
- Синхронізація «в реальному часі» без черги. Перше ж падіння CRM забирає з собою замовлення.
- Відсутність дедуплікації клієнтів. Через пів року в CRM три картки на одну людину й неможлива аналітика.
- Залишки раз на добу. Достатньо, щоб регулярно продавати те, чого немає на складі.
- Модулі з маркету «аби працювало». Автор зник, вихідники заплутані, оновити неможливо — і це виявляється саме тоді, коли треба терміново.
- Немає тестового середовища. Будь-яка зміна одразу на бойовому — питання часу, коли це закінчиться простоєм.
З чого почати
Якщо магазин уже працює, а зрозумілої картини немає, розумно почати з аудиту: версії й вразливості, стан модулів, швидкість каталогу, наявні інтеграції та їхні журнали. За підсумком видно, що треба лагодити терміново, а що — планово.
Ми робимо підтримку та супровід магазинів на OpenCart і власній CMS, а також розробку інтернет-магазинів з нуля й інтеграції з CRM під конкретний процес. Якщо хочете зрозуміти, що зараз відбувається з вашим магазином, — напишіть нам, подивимося разом.