Problema cu e-mailul: când aplicația ta creată cu IA trebuie să trimită mesaje unor oameni reali

Ai construit aplicația. Formularul de înscriere funcționează. Un utilizator îl completează, dă clic pe „Creează cont” — și apoi nu se întâmplă nimic. Sau mai rău: e-mailul de confirmare sosește patruzeci de minute mai târziu, în folderul de spam, cu o adresă de expeditor care arată de parcă a scris-o un robot. Îi ceri creatorului tău cu IA să „repare e-mailul”. Trei iterații mai târziu, ai un bug nou și aceeași problemă.

Dacă ai lansat ceva cu un creator de aplicații cu IA, probabil te-ai lovit de asta. E-mailul arată ca o funcție de o singură linie. Nu este. E un protocol vechi de treizeci de ani cu reguli de încredere ciudate, iar să-l faci să se comporte într-o aplicație creată cu IA e unul dintre cele mai comune locuri unde fondatorii non-tehnici își pierd utilizatorii în liniște.

Iată ce se întâmplă de fapt și ce să-i ceri creatorului tău să facă în privința asta.

De ce e e-mailul mai greu decât îl face creatorul tău să pară

Când creatorul tău cu IA generează o funcție de „trimite e-mail”, de obicei pune la punct cel mai mic lucru care funcționează pe un ecran de test. Folosește o adresă de expediere implicită. Trimite prin orice serviciu preferă șablonul lui. Presupune că ești o companie reală cu un domeniu real în care internetul are încredere.

Internetul real nu are încredere în expeditorii noi. Furnizorii de e-mail — Gmail, Outlook, Yahoo, Apple — au petrecut douăzeci de ani devenind buni la a semnala sursele necunoscute. Când un domeniu complet nou începe să trimită resetări de parolă și e-mailuri de bun venit, fiecare filtru de spam din lume ridică o sprânceană. Fără trei elemente specifice de configurare la locul lor, e-mailurile tale vor ajunge la spam, vor fi aruncate în liniște sau vor sosi suficient de târziu încât utilizatorii deja să fi renunțat.

Cele trei elemente sunt SPF, DKIM și DMARC. Nu trebuie să știi ce înseamnă. Trebuie să știi că fără ele, funcția ta de trimitere de e-mailuri e stricată într-un mod pe care nu-l poți vedea din interiorul aplicației.

Primul lucru de verificat: de la cine e de fapt e-mailul?

Deschide cel mai recent e-mail pe care l-a trimis aplicația ta. Uită-te la adresa de expeditor. De obicei e unul dintre trei lucruri:

1. Ceva@domeniultau.com — cazul cel mai bun. Creatorul tău cu IA a configurat un expeditor real. Dacă utilizatorii tot nu le primesc, problema e cele trei litere de mai sus.
2. Ceva@un-serviciu-de-creator.com — frecvent. E-mailurile tale sunt trimise din infrastructura partajată a creatorului tău. Asta funcționează, dar te bagă într-un grup cu fiecare altă aplicație la întâmplare de pe platformă. Un vecin rău și rata ta de livrare scade.
3. noreply@un-domeniu-la-întâmplare.example — rău. Creatorul tău cu IA a generat un substituent pe care nu l-a înlocuit niciodată. Utilizatorii primesc e-mailuri de la un domeniu care nu îți aparține, iar furnizorii de inbox îi vor suspecta pe bună dreptate.

Dacă ești în cazurile 2 sau 3, ăsta e primul lucru de reparat.

Ce să-i ceri creatorului tău cu IA, în ordine

Există o secvență specifică ce funcționează pentru cele mai multe creatoare. Să le ceri în ordinea greșită va produce rezultate confuze.

Pasul 1: alege un furnizor de trimitere

Cere-i creatorului tău cu IA: „Vreau să trimit e-mailuri de pe propriul meu domeniu. Conectează această aplicație la Resend (sau Postmark, sau SendGrid) folosind cheia mea API.” Alege unul. Sunt în mare echivalente pentru aplicații mici. Resend și Postmark au cele mai prietenoase fluxuri de configurare.

Va trebui să te înscrii tu însuți la furnizor și să obții o cheie API. IA nu poate face partea asta — necesită să introduci un card bancar și să-ți verifici identitatea. Alocă treizeci de minute.

Pasul 2: verifică-ți domeniul

Odată ce furnizorul tău de trimitere e conectat, furnizorul îți va cere să adaugi trei înregistrări DNS la domeniul tău. Acestea sunt înregistrările SPF, DKIM și DMARC pe care le-am menționat. Furnizorul tău îți va arăta exact ce să lipești.

Acesta e pasul pe care îl sar cei mai mulți fondatori non-tehnici și e cel care rezolvă 80% din plângerile „e-mailurile mele ajung la spam”. Cere-i creatorului tău cu IA: „Ajută-mă să găsesc unde să adaug înregistrări DNS pentru domeniul pe care l-am cumpărat.” Te va ghida prin registratorul tău (GoDaddy, Namecheap, Cloudflare, oricare ar fi).

Ăsta e și singurul pas care ia timp real — schimbările DNS pot dura câteva ore ca să se propage. Nu intra în panică dacă nu funcționează imediat.

Pasul 3: rescrie conținutul e-mailurilor

Ăsta îi surprinde pe oameni. Conținutul e-mailurilor tale contează la fel de mult ca și configurarea. Creatoarele cu IA folosesc implicit un text de marketing flecăreț care seamănă cu spamul. Două lucruri specifice de reparat:

• Niciun subiect scris cu majuscule. „BUN VENIT LA APLICAȚIA MEA” e un semnal de spam. „Bun venit la Bărci de la Maria” nu este.
• Niciun link gol către domenii de redirecționare. Dacă e-mailul tău spune „Dă clic aici” și linkul indică spre un URL de urmărire care ricoșează prin trei furnizori, filtrele de spam observă. Cere-i creatorului tău să folosească linkuri care merg direct la domeniul tău.

O verificare rapidă: trimite-ți un e-mail real din aplicație, apoi redirecționează-l către mail-tester.com. Îți punctează e-mailul de la 10 și îți spune exact ce să repari. Un scor de 8 sau peste înseamnă că inbox-urile te vor accepta. Sub 6, așteaptă-te la probleme.

Cele trei e-mailuri care trebuie să funcționeze

Nu trebuie să trimiți fiecare e-mail bine. Trebuie să trimiți trei e-mailuri specifice bine, pentru că dacă vreunul dintre ele eșuează, aplicația ta se strică pentru utilizatorii noi.

1. Confirmarea de înscriere. Dacă utilizatorii se înscriu și nu-și pot confirma adresa, nu se pot autentifica. Asigură-te că ăsta sosește în mai puțin de un minut, de fiecare dată.
2. Resetarea parolei. Ăsta e e-mailul pe care utilizatorii îl observă când lipsește. Dacă cer o resetare și nu sosește nimic, inbox-ul tău de suport se umple în aceeași zi.
3. E-mailul „s-a întâmplat ceva în contul tău” — o autentificare nouă, o invitație, un comentariu. Acestea construiesc încredere. Dacă apar în mod fiabil, utilizatorii încep să-ți trateze aplicația ca pe un serviciu real.

Orice altceva — newslettere, actualizări de produs, campanii prin picurare — e bonus. Fă cele trei e-mailuri de bază să se livreze constant înainte să construiești ceva sofisticat.

Când să ceri ajutorul unui om

Dacă ai făcut cei trei pași de mai sus și e-mailurile tot ajung la spam, problema e aproape mereu unul dintre trei lucruri: domeniul tău e prea nou (așteaptă o săptămână, trimite cu zgârcenie), conținutul tău declanșează un filtru anume (rulează verificarea mail-tester) sau volumul tău de trimitere a sărit brusc (începe mic, crește treptat).

Dacă ai petrecut mai mult de o zi pe asta și tot e stricat, ăsta e momentul potrivit să plătești un freelancer pentru două ore. Capacitatea de livrare a e-mailurilor e unul dintre puținele lucruri dintr-o aplicație modernă unde un om cu experiență poate repara ce un creator cu IA nu poate raționa pe deplin — pentru că răspunsul trăiește adesea în înregistrări DNS pe care IA nu le poate vedea.

Poți lansa o întreagă aplicație creată cu IA fără să pui vreodată la punct e-mailul real. Nu poți păstra utilizatorii fără el.