Strumenti

Rails si è costruito la sua reputazione sulla rapidità: impostazioni predefinite sensate, convenzioni anziché configurazione, e applicazioni basate su database messe in piedi in giorni anziché in mesi. Un CRM è esattamente il tipo di applicazione a cui questa forma si addice. È fatto soprattutto di record, delle relazioni fra di essi, e di un flusso di lavoro disteso al di sopra.

La domanda torna quindi con regolarità: se un'azienda gira già su Rails, può girare lì anche il suo CRM? La risposta onesta è che il campo è molto più ristretto di quanto i risultati di ricerca lascino intendere, e che la maggior parte di ciò che viene elencato come un "CRM Rails" non è affatto scritta in Ruby.

Fat Free CRM, il punto di riferimento

L'unico progetto che risponde davvero alla descrizione è Fat Free CRM. Il suo README lo definisce "an open source, Ruby on Rails customer relationship management platform (CRM)", ed è da anni la risposta predefinita a questa domanda. Copre la collaborazione di gruppo, la gestione delle campagne e dei lead, gli elenchi di contatti e il monitoraggio delle opportunità.

Da subito offre anche campi personalizzati, tag e l'organizzazione in gruppi e team, con plugin per i webhook, la fusione dei record e il monitoraggio del tempo. È distribuito sotto licenza MIT, raccomanda Ruby 3.1 o successivo, e funziona su MySQL, SQLite o PostgreSQL. Al momento in cui scriviamo il suo repository mostra circa 3.600 stelle e 1.300 fork, con un numero contenuto di issue e pull request aperte: costante anziché in rapido movimento.

Ciò che la maggior parte degli elenchi di CRM Rails sbaglia

Cerca un CRM Rails e troverai elenchi che mettono SuiteCRM, EspoCRM e Odoo accanto a Fat Free CRM. Questo raggruppamento è fuorviante. SuiteCRM ed EspoCRM sono applicazioni PHP appoggiate a MySQL o MariaDB, e Odoo è costruito in Python e gira su PostgreSQL.

Tutti e tre sono ottimi CRM open source. Nessuno di loro è un CRM Rails. Se il motivo della domanda era "lo voglio dentro il mio stack Ruby", quei tre non vi rispondono, e nessuna quantità di strumenti di deployment compatibili con Rails cambia il linguaggio in cui è scritta la base di codice.

La domanda che decide davvero

La domanda utile non è dunque quale sia il miglior CRM Rails, ma perché debba essere Rails. A questo esistono buone risposte. Condividere modelli e database con un'applicazione esistente, riutilizzare la stessa autenticazione, effettuare il deployment attraverso un'unica pipeline, e avere un proprio team in grado di leggere e modificare il codice sono vantaggi reali.

Se nessuno di questi elementi vale nel tuo caso, il vincolo ti sta costando qualcosa. Lasciarlo cadere apre un campo molto più ampio e mantenuto meglio, e il linguaggio in cui è scritto un CRM smette di contare nel momento in cui vi interagisci attraverso un browser e un'API.

A che punto ti lascia

Se il requisito Rails è reale, Fat Free CRM è il punto da cui partire, ed è meglio trattarlo come una base da estendere anziché come un prodotto finito da accendere. Questo significa mettere in conto la personalizzazione e il mantenerlo aggiornato, allo stesso modo in cui faresti per qualsiasi applicazione che ti appartiene.

In un caso come nell'altro sei tu a ospitarlo, il che significa che il CRM ha bisogno di un posto affidabile dove vivere, con il controllo sul runtime, sul database e sulla rete. È questa la parte che i team sottovalutano: il codice è gratuito, le operazioni no.