Jau veikianti el. parduotuvė: ką patikrinti prieš perkant

Pardavėjas atidaro nešiojamąjį kompiuterį, pasuka ekraną į Jus, parodo diagramą su kylančia kreive ir pasako skaičių, kurį iškart lydi kiti skaičiai ir teiginiai: parduotuvė veikia, apyvarta tokia, pirkėjų srautas toks, o kaina štai tokia. Viskas atrodo tvarkinga, ir būtent todėl verta sustoti, nes beveik kiekvieną iš šių teiginių galima patikrinti, ir beveik nė vienas iš jų nėra tikrinamas, kol sutartis dar nepasirašyta.

Šis straipsnis yra apie techninį patikrinimą prieš perkant jau veikiančią el. parduotuvę, ir jis nėra apie tai, kiek tokia parduotuvė verta, nes vertinimas ir mokesčių klausimai yra kitų žmonių darbas, kurio čia sąmoningai neliečiame. Apie tai, kaip parduotuvę sukurti nuo nulio, esame rašę atskirai, kaip ir apie tai, kiek kainuoja el. parduotuvės kūrimas. Čia kalba apie visai kitą situaciją: parduotuvė jau egzistuoja, ji turi istoriją, ir klausimas yra, kas iš šios istorijos iš tikrųjų pereina Jums ir kas lieka pas pardavėją.

Prieiga prie analitikos parodo mažiau, nei atrodo

Pirmas dalykas, kurio prašo kiekvienas protingas pirkėjas, yra skaitymo prieiga prie Google Analytics, ir tai teisinga, bet to nepakanka, nes ši prieiga įrodo mažiau, nei dauguma žmonių mano. Google Analytics 4 turi penkis vaidmenis, būtent administratorių, redaktorių, rinkodaros specialistą, analitiką ir žiūrintįjį, ir būtent žiūrinčiojo vaidmuo paprastai skiriamas pirkėjui: žiūrintysis mato nustatymus ir duomenis ir gali keisti tai, kas rodoma ataskaitose, bet negali tvarkyti naudotojų ir keisti nuosavybės nustatymų.

Pats suteikimas jau ką nors pasako, nes naudotoją pridėti gali tik administratorius, o naudotojai identifikuojami pagal Google paskyros el. pašto adresą, todėl pardavėjas, kuris negali suteikti skaitymo prieigos, nėra tos nuosavybės administratorius, ir tai klausimas, kurį reikia užduoti iškart. Ekrano kopija nėra prieiga, ir pokalbis, kuriame pardavėjas rodo savo ekraną, nėra prieiga ir tada, kai skaičiai atrodo įtikinami.

Toliau eina detalė, kurią žino nedaugelis ir kuri gali visiškai apversti išvadą, nes Google Analytics leidžia nuosavybei uždėti duomenų apribojimus, ir du iš šių apribojimų liečia būtent pinigus: vienas iš jų slepia išlaidų rodiklius, o kitas slepia pajamų rodiklius. Apribotos reikšmės ataskaitose nerodomos, ir naudotojas jų vietoje mato nulį. Pirkėjas, kuris pajamų stulpelyje mato nulius, todėl nėra pamatęs, kad parduotuvė neuždirba, o galbūt yra pamatęs apribojimą, ir vienintelis būdas tai išsiaiškinti yra paklausti, ar apribojimas uždėtas.

Yra ir bendresnė riba, kurią verta turėti omenyje visą patikros laiką, ir ji liečia patį matavimą: analitika rodo tai, ką užregistravo įdiegtas matavimo kodas, o ne tai, kiek žmonių iš tikrųjų atėjo. Kodas, uždėtas tik ant padėkos puslapio, kodas, kuris suveikia du kartus, kodas kūrimo aplinkoje arba vienas ir tas pats kodas, aptarnaujantis kelias svetaines, ataskaitoje atrodo kaip apsilankymai. Nė vienas iš šių atvejų nėra sukčiavimas pagal apibrėžimą, bet kiekvienas iš jų paverčia skaičių kuo kitu, nei pirkėjas mano.

Search Console yra kitas objektas ir kita patikra

Google Search Console rodo tai, ką pats Google užregistravo apie svetainės rodymąsi paieškos rezultatuose, todėl ji iš dalies nepriklauso nuo pardavėjo įdiegto matavimo kodo, ir būtent ši nepriklausomybė daro ją vertingesnę už analitiką, nors skaičiai ten mažesni ir mažiau glostantys. Vaidmenys ten kiti nei analitikoje: savininkas, visateisis naudotojas, ribotas naudotojas ir susietasis naudotojas, ir nuosavybė turi turėti bent vieną patvirtintą savininką, kitaip prieigos nėra niekam.

Ribotas naudotojas mato našumo ataskaitą, taigi užklausas, paspaudimus, parodymus ir vidutinę poziciją, bet negali pridėti naudotojų, pateikti svetainės schemos ar visiškai patikrinti konkretaus adreso, todėl pirkėjui to pakanka paieškos srautui pamatyti, bet nepakanka nuosavybei perimti. Tai sąmoningas skirtumas, kurį verta suprasti prieš pokalbį, nes pardavėjas, kuris siūlo tik riboto naudotojo prieigą, siūlo skaičius, o ne galimybę perimti.

Yra ir klausimas, kokia sena pati istorija, ir jis dažnai lemia daugiau nei skaičių dydis, nes Google pradeda rinkti duomenis apie nuosavybę jau tada, kai kas nors ją prideda, dar prieš patvirtinimą, todėl neseniai sukurta nuosavybė negali rodyti kelerių metų istorijos, nepriklausomai nuo to, kiek laiko parduotuvė veikia. Paklauskite, kada nuosavybė buvo sukurta, ir palyginkite tai su skelbiamu parduotuvės amžiumi.

Dabar apie tai, ką šis įrankis gali parodyti neteisingai, ir tai nėra teiginiai apie pardavėjų nesąžiningumą, o tiesiog mechanika: nuosavybė gali būti dviejų rūšių, būtent adreso priešdėlio nuosavybė, kuri apima tik vieną adresą su protokolu, ir domeno nuosavybė, kuri apima visą domeną su visais subdomenais. Domeno nuosavybė todėl gali sumaišyti į vieną skaičių parduotuvės ir visiškai atskiro tinklaraščio srautą, ir vienintelis būdas tai pamatyti yra pažiūrėti, kokio tipo nuosavybė atidaryta.

Antras mechanikos klausimas yra patvirtinimas, ir jis vyksta taip: nuosavybės teisės patvirtinamos įrodymu svetainėje, ir vienas iš leistinų būdų yra būtent Google Analytics matavimo kodas. Tai reiškia, kad abu įrankiai gali būti patvirtinti tuo pačiu kodu, kurį valdo tas pats žmogus, todėl dvi iš pažiūros nepriklausomos patikros gali pasakoti apie tą pačią, galbūt neteisingą svetainę. Be to, nepanaudoti patvirtinimo įrodymai leidžia anksčiau pašalintam savininkui patvirtinti save iš naujo, todėl pirkėjui, tapus savininku, reikia peržiūrėti, kokie įrodymai svetainėje dar likę.

Galiausiai verta žinoti istorinio lango ribą, kuri čia griežta: našumo duomenys saugomi šešiolika mėnesių, todėl trejų metų augimo istorijos iš šio įrankio neįmanoma ištraukti, ir pardavėjas, kuris tai žada, turi įrodyti kuo kitu. Ir paskutinis: nėra teisinga tikėtis, kad analitikos ir paieškos įrankio skaičiai sutaps, nes jie matuoja skirtingus dalykus, ir joks Google dokumentas nežada kokio nors nustatyto santykio tarp jų.

Eksportas nėra parduotuvė

Antra didelė bėda slypi žodyje eksportas, nes pirkėjas jį supranta kaip parduotuvės kopiją, o praktikoje tai konkrečių lentelių išrašas su konkrečiomis ribomis. WooCommerce branduolyje yra prekių importo ir eksporto įrankis, ir jis tikrai veikia, bet tai prekių įrankis: klientų ir užsakymų jis visai neapima, ir jiems reikia arba mokamo įskiepio, arba tiesioginės prieigos prie duomenų bazės.

Paveikslai yra atskira smulkmena su neproporcingai didelėmis pasekmėmis, ir priežastis yra eksporto mechanikoje: prekių eksportas dirba su paveikslų adresais, o ne su pačiais failais, todėl importo metu paveikslai turi būti pasiekiami, ir pagrindinis įrankis neperkelia paveikslų alternatyviųjų tekstų. Parduotuvei su keliais tūkstančiais prekių tai reiškia, kad po perkėlimo dalies paveikslų gali tiesiog nebūti, ir tai paaiškėja tik tada, kai derėtis dėl kainos jau per vėlu.

Uždaresnėse platformose ribos griežtesnės, ir jas reikia žinoti prieš pokalbį apie kainą, o ne po jo: slaptažodžių maišos reikšmės paprastai nepereina, ir tai reiškia, kad visiems esamiems klientams po perkėlimo teks atnaujinti slaptažodžius, o tai tiesioginis klientų praradimas, kurį pardavėjas minės retai. Dizaino šablono licencija dažnai lieka prie pardavėjo paskyros, papildiniai yra atskiros prenumeratos su savomis licencijomis, o užsakymų istorijos dalis platformų apskritai neleidžia įkelti atgal per administravimo skydelį.

Prie to paties priklauso trys smulkmenos, kurias prisimena retai ir kurios kiekviena atskirai kainuoja pinigus. Dovanų kortelės su likučiu yra įsipareigojimai klientams, ir jos ne visada pereina kartu su kitais duomenimis, todėl klausimas, kiek nepanaudoto likučio parduotuvėje yra, priklauso kainos pokalbiui. Saugumo sertifikatas neperkeliamas kaip turtas, o išduodamas iš naujo naujojo turėtojo vardu, ir tai rutina tik tada, kai domenas jau Jūsų rankose, o dizaino šablono licencija dažnai pririšta prie pardavėjo paskyros, todėl po perkėlimo gali paaiškėti, kad išvaizdą reikia pirkti dar kartą.

Iš to išplaukia patikros žingsnis, kuris nieko nekainuoja ir pasako daug. Paprašykite pardavėjo parengti bandomąjį eksportą dar prieš sutartį ir atidarykite jį patys, nes ten iškart pamatysite, ar jame yra klientų, ar užsakymuose yra prekių eilučių, ar paveikslai turi adresus ir ar kas nors iš to, kas parduotuvėje matoma, faile apskritai neatsiranda.

Domenas pereina teisių perleidimu, o ne įrašo pakeitimu

Domeno dalis yra ta, kurioje pirkėjai painioja tris visiškai skirtingas operacijas, ir ši painiava paprastai baigiasi tuo, kad domenas lieka pardavėjo vardu. Vardų serverių keitimas tėra nurodymas, kas aptarnauja domeno įrašus, ir su teisėmis į domeną jis neturi nieko bendra; paslaugų teikėjo keitimas pakeičia tai, kas domeną aptarnauja; o teisių į domeną perleidimas yra tai, kas pakeičia, kieno vardu domenas įregistruotas.

Lietuvos .lt domenams teisių perleidimo tvarką nustato DOMREG, ir būtent ši procedūra saugo domeno turėtojus nuo to, kad kas nors svetimas perrašytų domeną sau. Dabartinis turėtojas inicijuoja perleidimą savo paskyroje svetainėje www.domreg.lt/registrant, nurodęs įgijėjo, fizinio ar juridinio asmens, duomenis; įgijėjo pasirinktas akredituotas paslaugų teikėjas procedūrą turi užbaigti per 7 kalendorines dienas. Jei per tą terminą ji neužbaigiama, inicijuoti reikia iš naujo. Jei domeną aptarnauja paslaugų teikėjas, užbaigimas eina per jį, o ne tiesiai į registrą.

Dvi detalės šioje tvarkoje svarbesnės už kitas, ir pirmoji iš jų yra ta, kad perleidimas neleidžiamas, jei nepraėjo 30 kalendorinių dienų nuo domeno įkūrimo, nuo paskutinio perleidimo arba nuo įkūrimo karantino laikotarpiu, todėl kitą perleidimą galima daryti tik praėjus tam terminui, ir tai reikia įskaičiuoti į sandorio grafiką. Antroji yra ta, kad įgijėjo vardas, pavardė arba juridinio asmens pavadinimas turi sutapti su tuo, ką nurodo įgijėją aptarnaujantis paslaugų teikėjas; jei nesutampa, procedūra neužbaigiama.

Atskiro dėmesio vertas atvejis, kai pardavėjas yra įmonė, kurią ketinama likviduoti, nes būtent čia parduotuvės pirkimas gali baigtis domeno praradimu. Perleidimą inicijuoja dabartinis turėtojas savo paskyroje, todėl procedūrą reikia atlikti, kol tas turėtojas dar gali prisijungti, o karantinas perleidimą blokuoja. .lt registre nėra atskiros taisyklės, kuri po įmonės pabaigos trumpam paliktų vardą laisvą bet kam. Pirkėjui, kuris laukia, kol pardavėjas susitvarkys reikalus, gali nebelikti kam tą mygtuką paspausti.

Mokėjimų paskyra nepereina su pirkimo sutartimi

Prielaida, kad kartu su parduotuve pereina ir mokėjimų priėmimas, yra paplitusi ir neteisinga, bet lygiai taip pat neteisinga sakyti, kad mokėjimų paskyros perkelti visai negalima, nes teisinga formuluotė yra per vidurį: pirkimo sutartis pati savaime paskyros nepajudina, bet mokėjimo paslaugų teikėjas turi savo tvarką ir gali ir atsisakyti.

Stripe savo dokumentacijoje aprašo būtent šį atvejį, nurodydama, kad esamas paskyros savininkas, kuris nori perduoti paskyrą kitam, pavyzdžiui, parduodant įmonę, pirmiausia turi susisiekti su pagalbos tarnyba, kad išsiaiškintų, kokią informaciją reikia atnaujinti. Po to keičiami banko sąskaitos duomenys išmokoms, įmonės juridinis pavadinimas, mokesčių mokėtojo numeris ir atstovo duomenys, be to, įmonė tiesiogiai perspėja nesiųsti naujojo savininko duomenų el. paštu, o jei įmonė perimta kitos valstybės juridinio asmens, tvarka yra kitokia.

Yra dar viena detalė, kuri liečia būtent duomenis ir kurią pirkėjai sužino vėlai: jei perėjimas vyksta ne perimant tą pačią paskyrą, o persikeliant į naują, tada tarp dviejų paskyrų galima nukopijuoti klientus ir mokėjimo būdus, bet atskiri mokėjimai, sąskaitos, planai ir prenumeratos, kuponai, įvykiai ir žurnalai nekopijuojami. Parduotuvei su prenumeratomis tai kritiška, nes prenumeratų nutraukimas reiškia pajamų nutraukimą, ir šį klausimą reikia užduoti prieš sandorį, o ne po jo.

Lietuvos bankų ir vietinių mokėjimo tarpininkų įsigijimo sutarčių sąlygų čia nenaudojame, nes jų šiai patikrai neskaitėme, ir sąžiningiau tai pasakyti, nei užpildyti spėjimu, todėl tai sąmoninga spraga, o ne praleidimas. Jei parduotuvė priima mokėjimus per Lietuvos banką ar vietinį mokėjimo tarpininką, klausimą, ar sutartį galima perduoti, reikia užduoti būtent tam paslaugų teikėjui, ir Stripe tvarkos ant jo perkelti negalima.

Klientų sąrašas yra teisiškai aštriausia dalis

Čia yra vieta, kurioje pirkėjas gali įsigyti ne turtą, o pareigą, ir būtent todėl šis skyrius parašytas kaip įspėjimas, o ne kaip pamokymas. Pradžia yra sandorio struktūroje: jei perkate akcijas (akcijų pirkimas-pardavimas), duomenų valdytojas lieka tas pats juridinis asmuo ir duomenų bazė nekeičia savininko; jei perkate parduotuvę kaip įmonę turtinį kompleksą iš kito subjekto (įmonės pirkimas-pardavimas), asmens duomenys patenka naujam duomenų valdytojui, ir tai visai kitas atvejis.

Bendrasis duomenų apsaugos reglamentas nieko nežada apie parduotuvių pirkimą, ir jame nėra straipsnio, kuris sakytų, kad klientų duomenų bazė pereina automatiškai. Turi būti teisėtas pagrindas pagal 6 straipsnį, ir yra informavimo pareiga: 13 straipsnis reikalauja nurodyti duomenų valdytojo tapatybę tada, kai duomenys gaunami, o 14 straipsnis, kuris taikomas būtent atvejui, kai duomenys gauti ne iš paties asmens, reikalauja naujajam duomenų valdytojui pranešti savo tapatybę, tikslus, teisėtą pagrindą, duomenų kategorijas ir šaltinį, ir tai padaryti ne vėliau kaip per mėnesį arba per pirmąjį susisiekimą.

Lietuvoje rinkodaros laiškams viršuje stoja dar vienas įstatymas, ir būtent jis yra šio skyriaus branduolys. Elektroninių ryšių įstatymo 81 straipsnis leidžia elektroninių ryšių paslaugas, įskaitant el. pašto siuntimą, naudoti tiesioginei rinkodarai tik gavus išankstinį abonento ar registruotojo sutikimą; nuo 2026 m. balandžio 22 d. tokio sutikimo nereikia, kai gavėjas yra juridinis asmuo, jei jam sudaryta aiški, nemokama ir lengvai įgyvendinama galimybė atsisakyti. Fiziniam asmeniui vienintelė išimtis, 81 straipsnio 2 dalis, parašyta tam, kuris, teikdamas paslaugas ar parduodamas prekes, gavo savo kliento el. pašto kontaktus: jis gali jais reklamuoti savo paties panašias prekes ar paslaugas, jeigu klientui suteikiama aiški, nemokama ir lengvai įgyvendinama galimybė nesutikti, kai duomenys renkami ir, jeigu klientas iš pradžių neprieštaravo, siunčiant kiekvieną vėlesnę žinutę. Be to vis dar reikia teisėto pagrindo pagal reglamentą.

Ir dabar tai, kas paverčia tai spąstais: minėta išimtis parašyta asmeniui, kuris adresus gavo savo komerciniuose sandoriuose, taigi tam pačiam, kuris klientus aptarnavo. Pirkėjas, kuris adresų negavo, nėra šis asmuo, todėl ankstesnio savininko išimtis kartu su failu nepereina.

Šis klausimas skirtingose šalyse išspręstas įvairiai, ir šį nesutapimą sąžiningiau parodyti, nei uždengti. Vokietijos duomenų apsaugos institucijų konferencija 2024 m. užėmė griežtą poziciją, laikydama, kad klientų duomenų bazės pardavimas kaip atskiras turtas paprastai reikalauja išankstinio sutikimo, o Ispanijos nacionalinis įstatymas (LOPDGDD 21 straipsnis) turi normą, kuri įmonės perėjimo atveju tvarkymą preziumuoja teisėtu, jei jis reikalingas veiklos tęstinumui. Lietuva tokios specialios taisyklės neturi, todėl pirkėjui lieka reglamentas, minėtas 81 straipsnis ir teisinė konsultacija dėl konkretaus sandorio.

Patikros, kurios nepriklauso nuo pardavėjo

Visos ankstesnės patikros priklauso nuo to, ką pardavėjas suteikia ir ką rodo jo nustatymai, todėl šalia jų verta sudėti bent vieną, kurios šaltinis kitas, ir paprasčiausia iš tokių patikrų yra serverio žurnalai, nes jie fiksuoja užklausas nepriklausomai nuo to, ar puslapyje apskritai įdiegtas matavimo kodas ir ar lankytojas sutiko su slapukais.

Tai nėra Google metodas ir joks Google dokumentas to nerekomenduoja, todėl ir mes to nepateikiame kaip oficialios rekomendacijos, o kaip praktiką, kurioje, palyginus žurnalų užklausų apimtį su analitikos sesijomis už tą patį laikotarpį, paprastai matyti arba protingas santykis, arba toks skirtumas, apie kurį verta klausti. Prieigą prie žurnalų paprastai duoda talpinimo valdymo skydelis, todėl ši patikra reikalauja talpinimo prieigos, ir būtent todėl ją verta prašyti kartu su kita.

Antras nepriklausomas šaltinis yra mokėjimo paslaugų teikėjo ataskaita, ir tai vienintelė iš visų, kuri rodo pinigus, o ne apsilankymus. Čia svarbus vienas skirtumas: ataskaita, kurią pardavėjas atsiunčia kaip dokumentą, nėra tas pats, kas ataskaita, kurią matote paties paslaugų teikėjo skydelyje, nes pirmąją gali parengti bet kas, antrosios ne, todėl prašykite prieigos prie skydelio arba bent bendro ekrano su juo atidarytu.

Yra dar viena patikra, kuri kainuoja penkias minutes ir kurią praleidžia beveik visi: pažiūrėti, kaip parduotuvė šiandien atrodo paieškoje, įvedus jos pavadinimą ir kelias prekių pavadinimų frazes. Jei parduotuvė teigia apie stabilų paieškos srautą, bet pati savo vardu nerodosi arba rodosi už prekybos aikštelių, kuriose pati parduoda, tada srautas ateina iš kitur, ir verta išsiaiškinti, iš kur, nes mokama reklama po sandorio gali tiesiog sustoti.

Trečia yra apskaitos pusė, kurios iš esmės neliečiame, bet kurios buvimą verta paminėti, nes ji vienintelė susieja visa kita su deklaruotais skaičiais, ir jei analitika, mokėjimų skydelis ir apskaita pasakoja tris skirtingas istorijas, tada problema nėra matavimo tikslumas, ir toliau tai jau ne techninis pokalbis.

Kodo ir platformos būklę galima patikrinti pigiai

Techninės būklės patikra skamba kaip brangus auditas, bet didžiąją dalį atsakymo galima gauti per kelias valandas ir iš viešų duomenų. Pirmas žingsnis yra išsiaiškinti platformos ir kalbos versiją ir palyginti ją su gamintojo skelbiamu palaikymo kalendoriumi, nes pasibaigus palaikymui nauji pažeidžiamumai nebepataisomi, nors parduotuvė toliau veikia lygiai taip pat kaip anksčiau.

Antras žingsnis yra įskiepių sąrašas kartu su jų atnaujinimo istorija, nes paliktas įskiepis yra kartu saugumo rizika ir paslėpta sąnauda: kada nors jį teks pakeisti, o keitimas veikiančioje parduotuvėje paprastai reiškia perrašyti ir viską, kas aplink jį pastatyta. Trečias yra klausimas, ar parduotuvė kada nors buvo nulaužta ir kas po to buvo padaryta, ir šį klausimą verta užduoti tiesiai, nes išsisukinėjantis atsakymas čia toks pat informatyvus kaip patvirtinantis.

Ketvirtas žingsnis liečia kodą, jei parduotuvė pritaikyta, ir jis arti klausimo, kurį esame nagrinėję atskirai straipsnyje apie tai, kas Jums priklauso, kai sistema parengta. Čia pakanka praktinės pusės: kur yra saugykla, kas prie jos gali prieiti ir ar ji pereina Jums kartu su parduotuve, nes saugykla pardavėjo asmeninėje paskyroje po sandorio lieka pardavėjo asmeninėje paskyroje, jei jos atskirai neperkeliama.

Šalia saugyklos yra prieigos ir raktai, ir jie paprastai būna išsibarstę po vietas, kurių niekas nėra užsirašęs: talpinimo skydelis, domeno paskyra, mokėjimų skydelis, el. pašto paslauga, išorinių paslaugų raktai ir analitika. Jų sąrašą verta paprašyti raštu prieš sandorį ir patikrinti po jo, nes raktas, kurio niekas neperdavė, paprastai paaiškėja tada, kai kas nors nustoja veikti, ir tuo metu pardavėjas jau yra išėjęs.

Penktas yra pasikartojančių sąnaudų sąrašas, kuris ateina kartu su parduotuve, ir jis paprastai ilgesnis, nei pirkėjas tikisi, nes ten įeina platformos prenumerata, atskiros įskiepių prenumeratos, dizaino šablonas, mokėjimo tarpininko komisiniai, talpinimas, domenas ir sertifikatai, ir kiekvienas iš jų turi savo atnaujinimo datą ir savo kainą po pirmojo termino. Šį sąrašą verta sudėti į vieną lentelę prieš aptariant kainą, nes būtent jis parodo, kokia yra tikroji mėnesio parduotuvės sąnauda.

Ko reikalauti prieš pasirašant

Visa tai, kas anksčiau, sueina į reikalavimų visumą, kuri neužima daug laiko ir kuri sąžiningam pardavėjui nesukelia sunkumų: analitikos pusėje tai žiūrinčiojo prieiga prie pačios nuosavybės, o ne ekrano kopijos, kartu su atsakymu, ar pajamų rodiklių apribojimas uždėtas, o Search Console pusėje riboto naudotojo prieiga kartu su nurodymu, kokio tipo nuosavybė atidaryta.

Duomenų pusėje tai bandomasis eksportas prieš sutartį, atsakymas, ar slaptažodžių maišos reikšmės pereina, ir aiškumas, kas nutinka su užsakymų istorija. Domeno pusėje tai patvirtinimas, kieno vardu domenas įregistruotas šiandien, ir susitarimas, kad teisių į domeną perleidimas vyksta prieš apmokėjimą arba kartu su juo, o ne po.

Mokėjimų pusėje tai klausimas mokėjimo paslaugų teikėjui, o ne pardavėjui, nes tik jis gali pasakyti, ar paskyra pereina ir kokiomis sąlygomis, ir pardavėjo įsitikinimas šiuo klausimu nėra įrodymas. Jei parduotuvėje yra prenumeratų, tada tą patį klausimą reikia užduoti dar kartą atskirai būtent apie jas, nes prenumeratos yra ta dalis, kuri perkėlime lūžta dažniausiai. Duomenų apsaugos pusėje tai aiškumas, kaip sąrašas buvo surinktas ir kas klientams tada buvo pasakyta, ir rašytinis susitarimas, kad po sandorio naujasis duomenų valdytojas įvykdys savo informavimo pareigą.

Ši reikalavimų visuma atrodo ilga, bet ji trumpesnė nei viena savaitė, kuri praeina bandant po sandorio atgauti domeną ar atkurti prenumeratas, ir didžiąją dalį to sąžiningas pardavėjas parengia per porą valandų. Pardavėjas, kuris šiems reikalavimams prieštarauja, tuo pačiu jau atsakė į svarbiausią klausimą, ir tai pigiausias įmanomas būdas tai išsiaiškinti.

Ir galiausiai yra du dalykai, kurių šis straipsnis sąmoningai nedaro, nes tai ne mūsų darbas ir apsimesti kita profesija būtų blogiausia, ką čia būtų galima padaryti. Mes neišsakome nuomonės, kiek parduotuvė verta, ir nepakeičiame teisininko klausimu apie konkretaus klientų sąrašo naudojimą, nes abu yra kitų žmonių darbas. Jei norite, kad techninę dalį patikrintume mes, prieš pasirašydami, susisiekite su mumis, ir tai padarome kartu su el. parduotuvių kūrimo komanda.