Aceasta este o actualizare de infrastructură comercială, nu o funcție de vitrină. Pentru un magazin care vinde abonamente, diferența dintre un draft order care știe ce plan are linia și unul care nu știe se traduce direct în facturi corecte sau în facturi pe care le corectezi manual. Iar unde e muncă manuală, există eroare și există timp pierdut.

Ce s-a schimbat concret în API

Shopify a adăugat suport pentru selling plans în draft orders odată cu versiunea 2027-01 a Admin GraphQL API. Sunt trei câmpuri noi, toate aditive, ceea ce înseamnă că o aplicație care nu le folosește continuă să funcționeze fără nicio modificare (sursa: Shopify Changelog).

Primul este DraftOrderLineItemInput.sellingPlanId. Acesta setează planul pe care vrei să îl aplici atunci când creezi sau actualizezi o linie de draft order. El funcționează în draftOrderCalculate, draftOrderCreate și draftOrderUpdate. O limitare importantă: planurile se pot atașa doar pe linii care sunt variante de produs, nu pe linii libere.

Al doilea este DraftOrderLineItem.sellingPlanApplication. Acesta returnează planul aplicat pe o linie dintr-un draft order salvat. Practic, poți citi înapoi ce ai scris, ceea ce sună banal până când ai un flux automatizat care creează drafturi și trebuie să verifice că planul chiar a prins.

Al treilea este CalculatedDraftOrderLineItem.sellingPlanApplication. Acesta returnează planul pe draftul calculat, deci poți vedea rezultatul înainte de a salva ceva. Aici e partea cu adevărat utilă pentru integrări serioase: verifici prețul, verifici planul, abia apoi confirmi.

Limitele pe care trebuie să le știi înainte să construiești

Documentația e clară și e bine că e clară, pentru că limitele astea sunt genul de lucru care îți rupe un sprint dacă le descoperi la mijloc.

Sunt acceptate doar planurile de abonament recurente și cele prepaid. Planurile cu facturare fixă, cum ar fi precomenzile sau „încearcă înainte să cumperi", nu sunt acceptate. Dacă modelul tău comercial se bazează pe precomenzi, funcția asta nu ți se adresează încă.

Nu sunt acceptate draft orders B2B, liniile custom și nici suprascrierile de preț pe liniile cu selling plan. Aici e o zonă sensibilă pentru magazinele care lucrează cu clienți business și negociază prețuri: dacă ai nevoie de preț negociat pe un abonament, combinația nu e suportată.

Și cel mai important: draftOrderComplete nu este încă suportat. Dacă apelezi draftOrderComplete pe un draft care are o linie cu selling plan, primești un user error și nu se creează nicio comandă. Alternativa indicată este trimiterea facturii draftului la checkout prin draftOrderInvoiceSend. Traducere: poți construi draftul cu plan, poți verifica, dar conversia în comandă trece prin checkout, nu prin API-ul de completare a draftului.

De ce contează pentru operațiunea de abonamente

Să fim direcți: abonamentele sunt unul dintre puținele mecanisme care mută un magazin din vânzări pe impuls în venit recurent. Iar venitul recurent trăiește sau moare pe operațiune. Un client care sună pentru că i s-a facturat greșit un abonament nu e o problemă de marketing, e o problemă de proces care costă retenție.

Până acum, un flux care crea draft orders pentru abonamente trebuia să ducă evidența planului în altă parte: un câmp meta, un tabel extern, un note atașat. Fiecare dintre aceste soluții e o sursă de divergență. Când planul stă pe linia draftului, în obiectul nativ, ai un singur adevăr. Iar posibilitatea de a citi planul calculat înainte de salvare înseamnă că poți prinde eroarea înainte să ajungă la client.

Pentru echipele care lucrează cu volume mari de drafturi, de exemplu prin agenți comerciali care închid abonamente manual, asta reduce un strat întreg de verificare manuală. Nu elimină verificarea, o mută mai devreme în flux, unde e mai ieftină.

Ce înseamnă pentru tine, antreprenor sau marketer în România

Dacă ai un magazin pe Shopify și vinzi abonamente, întrebarea nu este „ne trebuie asta?", ci „în ce flux ne doare cel mai tare acum?".

Cel mai probabil loc unde te lovește lipsa acestei funcții este zona de vânzare asistată. Un om din echipă vorbește cu clientul, stabilește un abonament, creează un draft order și trimite factura. Dacă draftul nu știe ce plan are linia, atunci cineva trebuie să noteze separat, iar cine facturează trebuie să citească notița. Aici apar erorile recurente, iar erorile recurente costă mai mult decât par.

Al doilea loc este raportarea. Dacă planul stă pe linia draftului și poți citi planul aplicat, poți construi rapoarte care leagă drafturile de tipul de abonament fără să faci matching manual între sisteme. Asta înseamnă că poți răspunde la întrebări de tipul „câte drafturi de abonament lunar au fost create luna trecută și câte s-au convertit" fără să reconstruiești lanțul de atribuire de la zero.

Al treilea loc este onestitatea în comunicare. Dacă ai pe site-ul românesc un abonament cu livrare recurentă, iar în spate fluxul e improvizat, clientul simte asta la prima factură greșită. Iar în piața românească, unde recurența încă se vinde cu efort, o factură greșită nu e doar o reclamație, e un motiv bun să renunțe.

Ce ai de verificat concret înainte să te apuci de implementare:

Unu, verifică ce tip de plan folosești. Dacă ai precomenzi sau „încearcă înainte să cumperi", funcția nu te acoperă. Nu forța.

Doi, verifică dacă fluxul tău trece prin draftOrderComplete. Dacă da, trebuie să îl mutați pe draftOrderInvoiceSend, ceea ce e o schimbare de proces, nu doar de cod. Discută cu cine face development înainte să promiți ceva în sprint.

Trei, verifică dacă ai draft orders B2B sau prețuri negociate pe abonamente. Dacă da, acea parte a fluxului rămâne pe soluția actuală.

Patru, verifică dacă ai linii custom în drafturi. La fel, nu sunt acoperite.

Recomandarea mea, și aici vorbesc ca recomandare, nu ca fapt din sursă: nu porni o migrare mare. Pornește cu un singur flux, cel cu cel mai mare volum sau cea mai mare rată de eroare, măsoară câte corecții manuale elimini și abia apoi extinde.

Unde se leagă de restul stackului de marketing

Această actualizare nu este o funcție de achiziție. Nu îți aduce clienți noi. Este o funcție de infrastructură comercială, iar valoarea ei se vede în retenție și în costul operațional.

Dar se leagă de discuția mai largă despre cum măsori. Dacă ai un flux de abonamente care funcționează curat, poți separa venitul recurent de vânzările unice în raportare, ceea ce schimba complet ce înseamnă un MER sănătos pentru tine. Despre problema de a produce volum fără claritate în spate am scris în mai multe reclame paid social nu rezolvă problema de creativ, iar logica se aplică și aici: mai multe drafturi nu rezolvă un flux rupt.

Totodată, dacă lucrezi cu secvențe de email pentru clienți noi, ai nevoie de date curate despre ce au cumpărat, inclusiv dacă au cumpărat un plan. Altfel secvența vorbește despre o singură cumpărare în timp ce clientul are un abonament activ. Am detaliat mecanismul în welcome email series: de ce secvența de 3-6 emailuri bate campania.

FAQ

Trebuie să fac ceva ca să nu mi se strice aplicația? Nu. Câmpurile sunt aditive, iar Shopify precizează explicit că nu e nevoie de nicio acțiune pentru ca aplicația să continue să funcționeze. Modificările sunt opționale și le faci doar dacă vrei să folosești funcția.

Pot aplica un selling plan pe orice linie de draft order? Nu. Doar pe linii care sunt variante de produs. Liniile custom nu sunt acceptate, iar draft orders B2B și suprascrierile de preț pe liniile cu selling plan nu sunt suportate.

Pot finaliza o comandă dintr-un draft care are selling plan? Nu încă. draftOrderComplete returnează un user error pe un astfel de draft și nu creează comanda. Poți trimite factura la checkout prin draftOrderInvoiceSend.

Ce tipuri de planuri sunt acceptate? Doar abonamentele recurente și cele prepaid. Planurile cu facturare fixă, precum precomenzile și „încearcă înainte să cumperi", nu sunt acceptate.

Concluzia ALLSoft

Uneltele bune nu decid nimic singure. AI-ul și API-urile îți fac treaba mai rapidă: îți structurează fluxul, îți semnalează unde se rupe lanțul, îți pregătește rapoartele. Dar cine decide dacă un flux de abonamente merită migrat, în ce ordine și cu ce risc rămâne un om: media buyer-ul sau operatorul care răspunde de cont. Iar execuția, adică trecerea de la „am citit că există" la „funcționează în magazinul meu fără să stric ce funcționa", este pasul pe care îl face ALLSoft Agency. Fără promisiuni umflate, cu verificare înainte de schimbare.