Perché un’unica casella per tutto non regge

La configurazione cresce piano piano. Il primo progetto riceve un contact@ alias che inoltra al tuo Gmail personale. Il secondo riceve lo stesso trattamento. Poi una landing page richiede un modulo e anche un endpoint inizia a inviarti email. Al decimo progetto hai dieci regole di inoltro, un filtro per dominio e un albero di etichette abbandonato da mesi. E una casella che finge di essere dieci.

Poi iniziano i problemi:

  • I messaggi si perdono. La segnalazione di un bug da un cliente pagante di un progetto finisce tra il picco di lancio di un altro e la tua posta personale. Il client email non sa che sono prodotti diversi. La trovi quattro giorni dopo.
  • Il contesto si perde. “Ehi, l’esportazione non funziona.” Quale esportazione? Metà dei messaggi non cita il progetto e l’unico indizio è un’intestazione To: sepolta in un inoltro.
  • Non puoi silenziare un solo progetto. La settimana di lancio di un prodotto sommerge la casella di tutti gli altri. L’unico interruttore per silenziarla copre la tua intera vita.
  • Non puoi delegare nulla. Un collaboratore entra in un progetto, ma i messaggi sono nel tuo account personale. Devi inoltrarli uno per uno o condividere le credenziali. Entrambe le opzioni sono sbagliate.
  • I progetti abbandonati non muoiono mai. La regola d’inoltro sopravvive al prodotto. Due anni dopo ricevi ancora spam per un dominio scaduto e non osi eliminare il filtro perché è intrecciato ad altri nove.

Non sono problemi di filtri. È un problema di struttura: fai passare N prodotti da un solo canale e usi le etichette come nastro adesivo.

Cosa cambia con una casella per progetto

Capovolgi il modello. Ogni progetto ha la propria casella: email, endpoint modulo e regole di notifica. I messaggi non si mescolano e ciò che era globale diventa specifico:

  • Il silenziamento resta limitato al progetto. Silenzia il progetto durante il lancio; gli altri nove continuano a notificarti.
  • Il passaggio resta limitato al progetto. Un collaboratore riceve i messaggi di quel progetto (in un canale Discord o Slack condiviso, o in una casella del team) senza mai accedere alla tua posta.
  • L’archiviazione resta limitata al progetto. Il progetto è finito? Archivia la casella. Il canale si chiude, lo storico resta leggibile e tutto il resto continua come prima.
  • Il contesto non costa nulla. Se un messaggio è nella casella, riguarda quel progetto. Non serve indagare negli header.

Puoi farlo con una casella a pagamento per progetto o un dominio catch-all e tante regole (alcuni lo fanno). Ma costa denaro per indirizzo o un pomeriggio per progetto: ecco perché nessuno continua oltre il terzo. La soluzione è rendere gratuita la creazione di una nuova casella.

La configurazione, in pratica

È proprio ciò che abbiamo creato mailcontact per. Crea un progetto: avrà due fonti che alimentano una sola casella:

Un indirizzo email subito funzionante. [email protected] è attivo appena esiste il progetto: nessun record DNS, server di posta o verifica. Mettilo nel piè di pagina ed è fatta. (Come funziona l’indirizzo.)

Un endpoint per i moduli per il modulo di contatto della landing page. L’invio HTML semplice email e message (più i campi facoltativi name e subject), inviato tramite lo script ospitato MailContact per restare sulla pagina:

<form action="https://mailcontact.app/api/forms/your-form-id" method="POST" data-mailcontact-form>
  <label>Email <input name="email" type="email" required /></label>
  <label>Message <textarea name="message" required></textarea></label>
  <button type="submit">Send</button>
  <p data-contact-status role="status" aria-live="polite"></p>
</form>
<script defer src="https://mailcontact.app/forms/v1.js"
  crossorigin="anonymous" referrerpolicy="no-referrer"></script>

Entrambi arrivano nella stessa casella del progetto, e un notifica (Discord, Slack, email o webhook) scatta appena arriva qualcosa, così non devi controllare un’altra casella. Dieci progetti, dieci caselle, zero nuove schede. Il documentazione spiegano i dettagli. Free include un progetto modulo; Pro include dieci progetti con un modulo e un indirizzo email ciascuno (prezzi).

Lo snippet sopra è volutamente indipendente dallo stack: dieci progetti raramente usano lo stesso strumento. Trovi guide specifiche per ciò che stai pubblicando: Next.js, Astro, SvelteKit, Hugo, oppure l’elenco completo.

Per chiarire l’ambito: mailcontact non è pensato come helpdesk. Nessun ticket, SLA o coda di assegnazione: solo una casella ordinata per progetto per i messaggi reali. Puoi crea un account gratuito per ottenere l’accesso.

Canali separati per una gestione ordinata

Nessuno mette dieci servizi in un file di log cercando poi il nome. Nessuno invia gli errori di dieci app a un progetto di monitoraggio. Nel resto dello stack, un canale per prodotto è normale igiene operativa. L’email di contatto fa eccezione solo perché isolarla costava: dominio, DNS e una postazione pagata per indirizzo.

Quando una nuova casella richiede cinque secondi anziché un pomeriggio, cambia tutto. Creare il canale contatti diventa parte dell’avvio del progetto, come inizializzare il repository. Avrebbe dovuto funzionare così da sempre.

Il prossimo progetto merita la sua casella. E anche i nove precedenti.