Plecarea unui client SaaS B2B: exportul datelor, accesul și închiderea contului

Offboardingul unui client SaaS B2B începe cu o dată de încetare confirmată și cu un export pe care clientul îl poate folosi. Anularea abonamentului în sistemul de plăți nu închide singură toate conturile, nu dezactivează integrările și nu demonstrează că datele au fost predate. Echipa trebuie să poată spune exact ce rămâne accesibil, până când și cine verifică fiecare etapă.

Imagine editorială generată cu OpenAI; scenă ilustrativă.

Confirmă data de oprire înainte să schimbi facturarea

Înregistrează solicitarea făcută de persoana autorizată din organizația clientului. Verifică cine poate cere încetarea, ce prevede contractul despre notificare și ce servicii sunt active. Un client poate avea mai multe spații de lucru sau contracte; închiderea unuia nu trebuie să oprească accidental accesul celorlalte. Trimite în scris data până la care produsul rămâne utilizabil și data estimată a ultimului export.

Mecanismul de facturare are propriile stări. Documentația Stripe despre configurarea portalului de clienți distinge între anularea imediată și cea la sfârșitul perioadei de plată. Referința pentru anularea unui abonament descrie și efectul asupra elementelor de factură aflate în așteptare. Nu echivala automat un clic pe „anulează” cu ultima zi de acces: verifică setarea folosită, starea abonamentului și clauza contractuală înainte de a comunica o dată.

Planifică și cazul unei cereri retrase. Dacă organizația se răzgândește înainte de oprire, persoana din suport trebuie să știe dacă abonamentul poate fi reactivat fără un cont nou și dacă exportul deja pregătit trebuie invalidat. Dacă decizia vine după ștergere, nu promite restaurarea unor date care nu mai există.

Pregătește un export care poate fi importat

Definește lista de obiecte promise: proiecte, documente, comentarii, atașamente, utilizatori, roluri, setări și istoricul relevant. Un fișier CSV cu numele proiectelor poate fi insuficient dacă relațiile dintre proiecte, utilizatori și atașamente se pierd. Furnizează un manifest cu fișierele incluse și explică ce câmpuri ori funcții nu pot fi exportate. Testează arhiva pe un cont de probă cu aceeași structură de date, apoi verifică dacă fișierele pot fi deschise și dacă numărul de obiecte corespunde inventarului.

Nu trimite arhiva printr-un link fără expirare sau unui utilizator care a părăsit compania clientului. Verifică administratorul destinatar, limitează durata linkului și consemnează momentul descărcării. O organizație cu două filiale poate avea date separate în același produs; exportul trebuie filtrat după spațiul potrivit. Include în test și permisiunile: persoana care poate închide abonamentul nu are neapărat dreptul să primească toate datele operaționale.

Regulile despre date personale cer o analiză separată. Articolul 20 din GDPR privește portabilitatea datelor persoanei vizate în condițiile prevăzute de regulament; nu înseamnă că orice contract B2B impune exportul integral al bazei de date comerciale în același temei. Ghidul Comitetului European pentru Protecția Datelor explică formatul structurat și citibil automat și condițiile dreptului la portabilitate. Distinge cererea contractuală a firmei de o cerere formulată de o persoană fizică pentru propriile date și cere verificarea responsabilului juridic atunci când se suprapun.

Oprește accesul în ordinea potrivită

După confirmarea primirii exportului sau la termenul contractual, dezactivează sesiunile, cheile API, conturile de serviciu și integrările. Inventariază și accesul acordat propriei echipe de suport la organizația clientului. Un utilizator care nu se mai poate conecta prin interfață poate avea încă un token activ pentru API; tocmai acesta trebuie testat după dezactivare.

Păstrează o urmă a operațiunilor: cine a aprobat închiderea, când a fost creat exportul, cine l-a descărcat, ce chei au fost revocate și ce verificări au eșuat. Ghidul despre jurnalul de audit în SaaS B2B explică de ce trebuie consemnat rezultatul, nu numai apăsarea unui buton. Nu pune în jurnal conținutul arhivei, parole sau tokenuri. Dacă un proces automat eșuează, cazul trebuie să ajungă la o persoană responsabilă, nu să fie marcat ca închis doar pentru că a expirat abonamentul.

Pentru un client cu integrare către sistemul contabil, un test concret este să încerci după dezactivare același apel API folosit pentru sincronizarea lunară. Răspunsul trebuie să arate că accesul a fost retras; verifică separat că alte organizații conectate la aceeași integrare nu au fost afectate. Această verificare este mai concludentă decât o bifă administrativă în interfață.

Spune ce se șterge și ce rămâne

Întocmește un inventar al datelor din producție, copii de siguranță, sisteme de analiză, suport și facturare. Stabilește pentru fiecare ce termen și temei se aplică, cine execută ștergerea și cum se confirmă. Articolul 17 din GDPR enumeră situațiile în care persoana vizată poate cere ștergerea, dar și excepții; o solicitare de închidere a contractului nu fixează singură aceeași regulă pentru toate categoriile de date. Nu promite „ștergere imediată din toate copiile” dacă restaurările și ciclul copiilor de siguranță funcționează altfel.

Documentează perioada în care arhiva de export mai poate fi descărcată și când va fi eliminată. Confirmarea finală pentru client ar trebui să conțină data opririi accesului, starea exportului, serviciile deconectate și explicația privind datele păstrate conform contractului sau obligațiilor aplicabile. Dacă un incident survine în timpul procesului, folosește procedura de răspuns din primele 60 de minute. Înainte de a închide tichetul, verifică din nou exportul și revocarea tokenurilor: acestea sunt cele două rezultate pe care clientul le poate proba direct.