Pyaterochka nu a sunat înapoi: cum am construit livrarea din supermarket fără un singur API

Pyaterochka nu a sunat înapoi: cum am construit livrarea din supermarket fără un singur API

Când am început să fac Vecin2Vecin — un serviciu de livrare de produse „de la vecin la vecin” — mi se părea că am o problemă tehnică clară. Utilizatorul alege un supermarket, umple coșul, un vecin-curier merge în magazin, cumpără și aduce la ușă. Pentru asta ai nevoie de un catalog live: nume de produse, prețuri, disponibilitate. Iar catalogul, gândeam eu, îl poți lua de la rețele — au aplicații, deci au date, deci trebuie să existe un API.

Asta s-a dovedit cea mai naivă presupunere din tot proiectul.

Așteptarea: „vă aducem comenzi — dați-ne un API”

Logica părea de neclintit. Nu concurez cu magazinul. Dimpotrivă — îi aduc vânzări în plus. Un vecin cumpără produsele lor, la prețurile lor, la casa lor. De la rețea am nevoie, practic, de un singur lucru: sortiment actual cu prețuri, ca cumpărătorul să vadă coșul înainte de comandă.

Am făcut o listă de rețele în țările unde lansam: în Rusia — Pyaterochka, Perekrestok, Magnit, Lenta, VkusVill și altele; în Moldova — Kaufland, Linella, Nr.1, Green Hills. Am scris departamentelor de parteneriat, B2B, digital. Am descris produsul, modelul, beneficiul. Am atașat link către aplicația funcțională.

Și am așteptat.

Realitatea: liniște

Nu a venit niciun răspuns. Nu „nu” — liniște. Uneori un răspuns automat: „mulțumim pentru mesaj”. Uneori „l-am transmis colegilor”. O dată — „nu e zona noastră de responsabilitate”, fără să spună a cui.

La început am crezut că am scris prost emailul. L-am rescris. Liniște. Am decis că scriu unde nu trebuie. Am găsit oameni pe LinkedIn, am trimis prin formulare „devino partener” de pe site-uri. Liniște.

La un moment dat mi s-a luminat: absența răspunsului este răspunsul. Și motivul nu e că produsul meu e slab.

De ce tăc rețelele (și nu e despre tine)

Când am încetat să o iau personal și am privit lucid, imaginea s-a conturat.

Au deja propria aplicație. Pentru o rețea mare, un serviciu de livrare terț nu e „vânzări suplimentare”, ci un competitor al canalului propriu. Au investit în livrarea lor și nu ard să dea clienții altcuiva.

Nu există proces pentru parteneri mici. Departamentele de parteneriat ale marilor rețele sunt făcute pentru agregatori de nivelul Yandex și Samokat — cu avocați, volume și garanții. Un email de la un startup cu MVP pur și simplu nu intră în KPI-ul nimănui. Rămâne suspendat între IT, marketing și achiziții, și nimeni nu se ocupă.

Datele sunt un activ. Sortimentul complet și prețurile sunt secret comercial. Un API deschis de sortiment e, practic, un cadou pentru concurenți și analiști de piață. Rețelele protejează aceste date intenționat.

Risc juridic. Dacă în catalogul meu prețul e greșit sau produsul e „în stoc pe hârtie”, dar nu pe raft — cine răspunde în fața cumpărătorului? Pentru rețea e risc de reputație fără un beneficiu clar.

Niciunul dintre aceste motive nu ține de calitatea produsului meu. Sunt bariere sistemice, și era important să le înțeleg înainte să mai pierd jumătate de an cu emailuri.

Ce am făcut în loc de API

Recunosc onest: încă nu am un API live de sortiment. Catalogul din aplicație se umple cu scripturi seed — seturi de produse tipice cu prețuri orientative pentru fiecare rețea. Pe landing scrie „prețurile și disponibilitatea se văd imediat”. Tehnic, pentru demo, e adevărat. Operațional și juridic — încă nu, și nu pretind că e altfel.

Dar exact aici proiectul a virat într-o direcție care s-a dovedit corectă.

Poate API-ul nici n-a fost necesar

Modelul meu nu e Instacart. Curierul nu e angajat al rețelei, ci cineva din același cartier. Comanda e adesea nu un SKU exact de pe raft, ci „lapte, pâine, ceva la ceai”. Și am înțeles: pentru un model de vecinătate, catalogul exact al rețelei nu e o condiție de lansare.

Ce contează cu adevărat:

• o listă de magazine de încredere și un set clar de produse;
• mecanica „vecinul cumpără după listă” cu bon;
• calcul onest: plată în avans, rambursare curierului pentru ce s-a cumpărat efectiv plus recompensă.

Tot asta e deja în logica mea de plăți. Cumpărătorul plătește dinainte, curierul cumpără, serviciul îi rambursează suma produselor și comisionul. Diferența dintre prețul așteptat și cel real se rezolvă la nivel de bon, nu la nivel de API perfect.

Cu alte cuvinte: alergam după o integrare de care au nevoie agregatorii mari, deși modelul meu are nevoie doar de încredere, bon și rambursare.

Ce abordări există

Dacă faceți ceva similar, iată o hartă onestă a variantelor — cu toate minusurile.

• Abordare — Plus — Minus
• API oficial / parteneriat — Legal, prețuri actuale — Rețelele nu răspund luni de zile
• Parsare site sau aplicație — Rapid, fără acorduri — Încălcarea regulilor, blocări, stricăciuni constante
• „Vecinul cumpără după listă” — Lansare fără rețea — Posibile diferențe de preț
• Catalog manual / demo — Control total — Nu scalează, prețurile expiră

Nu există glonț de argint. La start câștigă nu cine are mai multe SKU în bază, ci cine livrează comenzi și încasează bonul.

Ce mi-aș spune la început

Planificați luni, nu săptămâni, pentru retail. Conectarea la API nu e un sprint de inginerie. E vânzări, avocați și politică internă a rețelei. Adesea — fără succes.

Începeți cu un pilot, nu cu o integrare. Un cartier, listă limitată de produse, catalog manual sau chiar listă într-un messenger. Verificați dacă se închid comenzi, nu cât de frumos arată catalogul.

Măsurați metrica potrivită. Nu „câte produse în bază”, ci „câte comenzi livrate cu o diferență acceptabilă pe bon și un cumpărător mulțumit”.

Nu luați tăcerea personal. O rețea care n-a răspuns nu v-a evaluat produsul. Pur și simplu nu are proces să vă audă. Asta spune ceva despre cum e construită, nu despre ideea voastră.

Concluzie

Voiam un API de sortiment. În schimb am obținut un model funcțional: vecin, coș, bon din magazin și rambursare onestă. Supermarketurile tot nu au sunat — și, ciudat, proiectul n-a murit din cauza asta, ci și-a găsit forma adevărată.

Uneori zidul în care te lovești nu e un obstacol pe drum — e un semn că drumul ales nu era cel potrivit.