Magento B2B pe Hyvä: ce merge, ce se strică și cât timp cere

Cele mai multe estimări de migrare la Hyvä sunt făcute pentru un catalog B2C. Apoi cineva pomenește de conturi de companie și cifra se dublează. B2B-ul e cel mai mare multiplicator al unui termen pe Hyvä și e cel pe care și comercianții, și agențiile îl subestimează, pentru că funcțiile sună a backend și sunt aproape în întregime frontend.

Întâi, despre care B2B vorbim

În spatele aceluiași cuvânt se ascund două situații foarte diferite.

Pe Adobe Commerce, B2B e o suită oficială de module: conturi de companie cu ierarhie proprie de utilizatori, cataloage partajate, liste de rechiziție, oferte negociabile, comenzi de achiziție cu reguli de aprobare și plată pe cont. E un set de funcții mare și coerent și livrează o cantitate mare și coerentă de cod de magazin.

Pe Magento Open Source nu există B2B nativ. Ce numesc comercianții configurația lor de B2B sunt de obicei trei-patru extensii terțe plus ceva muncă la comandă: o afișare de preț pe grup de clienți aici, o cantitate minimă de comandă dincolo, un formular de cerere de ofertă construit de cineva în 2021. E mai mic, dar e făcut la comandă, ceea ce înseamnă că nimic din el nu apare pe niciun tracker de compatibilitate.

Distincția contează pentru că decide cine deține codul de frontend pe care urmează să îl rescrii. Un caz e o mărime cunoscută. Celălalt e un proiect de arheologie.

De ce B2B-ul e greu pe frontend

Aici se greșește. B2B-ul pare funcționalitate de backend, pentru că e despre reguli de preț, permisiuni și aprobări. Dar aproape totul ajunge la client sub formă de ecran, iar în Luma ecranele acelea sunt construite cu Knockout și cu componentele UI din Magento, adică exact stratul pe care Hyvä îl înlocuiește.

Logica de business de dedesubt trece migrarea neatinsă. Entitatea de companie, regulile de preț, motorul de aprobări, endpoint-urile de API: niciuna nu se sinchisește ce temă ai. Ce nu supraviețuiește e fiecare interfață pe care o atinge un cumpărător.

Ce se strică, ecran cu ecran

• Autoservirea contului de companie. Profilul companiei, ierarhia de utilizatori, rolurile și permisiunile, invitarea unui coleg. E o mică aplicație care trăiește în zona de cont a clientului și e în întregime strat de afișare.
• Listele de rechiziție. Adăugare, editare, recomandare dintr-o listă salvată. Foarte interactive, foarte Knockout în Luma.
• Ofertele negociabile. Cererea, schimbul de mesaje, expirarea, transformarea ofertei în comandă. E cea mai complexă suprafață din Magento B2B și cea mai des subestimată.
• Comenzile de achiziție și fluxurile de aprobare. Cumpărătorul trimite, aprobatorul vede o coadă, regulile decid cine trebuie să semneze. Mai multe ecrane, mai multe stări.
• Catalogul partajat și afișarea prețurilor pe grup de clienți. Nu logica de preț, ci afișarea ei. Vezi mai jos, pentru că aici e o capcană.
• Checkout-ul. Plata pe cont, comanda de achiziție ca metodă de plată, finalizarea unei oferte. Checkout-ul e deja un proiect separat la orice migrare Hyvä, iar B2B-ul îl face mai mare.

Capcana prețurilor pe grup de clienți

Merită o secțiune proprie pentru că prinde și echipe experimentate.

Prețurile pe grup de clienți și pe tranșe sunt livrate frecvent prin mecanismul de conținut privat din Magento, ca o singură pagină din cache să poată servi toți clienții, iar prețul corect să fie completat ulterior de JavaScript. E un design rezonabil și funcționează bine pentru un om cu un browser.

Are însă două consecințe pe care merită să le decizi deliberat, nu să le moștenești. Cumpărătorul vede o clipă prețul de listă înainte ca prețul lui contractual să îl înlocuiască, ceea ce pe o conexiune lentă arată ca o eroare de preț și generează tichete de suport. Și, pentru că prețul nu e în HTML, e invizibil pentru orice nu execută JavaScript, adică pentru toate crawlerele AI importante și pentru orice colector de feed-uri.

O reconstrucție pe Hyvä e momentul să decizi dacă schimbul acela mai e potrivit. Pentru un magazin B2B unde fiecare cumpărător autentificat vede alt preț, punerea paginii în cache și completarea prețului e de obicei corectă. Pentru unul unde prețurile sunt publice și diferă doar discounturile de volum, deseori nu este.

Cât au durat, de fapt, proiectele publicate

Agențiile care publică intervale de timp sunt de acord asupra direcției, chiar dacă nu și asupra cifrelor. Un catalog standard e cotat frecvent la opt până la paisprezece săptămâni. Adăugarea modulului B2B din Adobe Commerce împinge aceeași estimare la douăsprezece până la optsprezece săptămâni, iar un alt interval publicat pune un B2B complet pe Adobe Commerce la douăsprezece până la șaisprezece.

Indexul de studii de caz al Hyvä e dovada mai bună, pentru că proiectele au nume. O implementare completă a suitei B2B din Adobe Commerce a durat patru luni, cu doi specialiști Magento interni la client. Un magazin B2B multi-brand și multilingv a durat trei luni. Cel mai lung proiect indicat pe tot indexul, douăzeci de săptămâni, a avut patru store view-uri internaționale plus un rebranding.

Deci cifra onestă de planificare pentru un magazin B2B real e trei până la patru luni, nu opt săptămâni. Dacă o ofertă spune altceva, întreabă care dintre cele șase ecrane de mai sus intră în scop.

Cum estimezi fără să ghicești

Inventariază ecranele, nu funcțiile. Sună pedant și e tot secretul. Un magazin poate avea modulul B2B activat și să folosească trei din cele opt funcții ale lui, caz în care reconstruiești trei suprafețe, nu opt.

Scoate datele reale de utilizare înainte să estimeze cineva. Câte companii au mai mult de un utilizator? Câte liste de rechiziție există și când au fost atinse ultima dată? Câte oferte s-au emis în ultimul an? Pe un număr surprinzător de instalări B2B, răspunsul la cel puțin una dintre ele e zero, iar o funcție pe care nu o folosește nimeni e o funcție pe care nu o portezi.

Apoi decide deliberat unde e acceptabil fallback-ul pe tema Luma. Zona de cont de companie e o candidată bună: e pentru utilizatori autentificați, cu trafic mic, neindexată, iar câștigul de viteză acolo valorează foarte puțin. Să o ții pe Luma la prima lansare și să o reconstruiești mai târziu e un plan legitim, atât timp cât are o dată atașată. Am tratat mecanismul și compromisurile acelui fallback în ghidul despre migrarea unui magazin activ la Hyvä.

În final, estimează checkout-ul ca proiect separat, cu buget separat, și auditează-ți extensiile înainte să te angajezi la ceva. Magazinele B2B au tendința să ducă mai multe integrări decât cele B2C, iar compatibilitatea extensiilor e ce decide dacă estimarea ține.

Partea pe care nimeni nu o trece în ofertă

Cumpărătorii B2B nu se plimbă prin magazin. Recomandă ceva, verifică un preț contractual și se întorc la treabă. Argumentul de performanță pentru Hyvä pe un magazin B2B e mai slab decât pe unul de consum, pentru că clienții tăi nu te vor abandona pentru 400 de milisecunde.

Argumentele reale sunt altele și merită spuse direct. Viteza de dezvoltare crește, deci modificările pe care le tot cere echipa de vânzări nu mai durează două săptămâni. Frontend-ul devine întreținut de oameni care nu sunt specialiști Magento. Și nu mai cari un stack de JavaScript din 2010, cu care pot lucra tot mai puțini dezvoltatori de la an la an.

Dacă niciunul dintre acestea nu contează pentru tine acum, o migrare B2B la Hyvä e un lucru pe care îl poți amâna justificat. E un răspuns legitim și nu îl auzi des.

Programează un apel gratuit de strategie

Trimite-ne configurația ta de B2B și îți spunem ce ecrane sunt de fapt folosite, care trebuie reconstruite, unde fallback-ul pe Luma e alegerea corectă și cum arată onest termenul. Programează un apel gratuit de strategie.