WPsigner compare ora come integrazione WPsigner nella directory di Uncanny Automator.
Cambia il lavoro di tutti i giorni. Un contratto firmato non finisce più in una casella che qualcuno deve aprire a mano. La firma può iscrivere una persona, etichettare un contatto, avvisare un canale o archiviare il PDF. Vale anche il contrario: un ordine, un modulo o qualsiasi altro trigger di Automator può creare e inviare il contratto.
Le ricette girano sul tuo server WordPress. Non c’è un passaggio da Zapier né una connessione a un’app remota. Documento, firmatari e traccia di audit restano su quel sito.
Che cosa si sblocca
Prima di questo add-on, collegare WPsigner al resto del sito passava da un webhook, una chiave API o un plugin su misura. Automator è già in mezzo ai plugin che molti siti usano. WPsigner ora parla quella lingua.
Cinque cambiamenti concreti:
- Il passo successivo parte da solo. Completato, rifiutato, visualizzato, scaduto: ognuno può avviare una ricetta senza copiare l’email del firmatario in un altro strumento.
- Il contratto esce da eventi che già segui. Un ordine pagato o un modulo possono creare un documento da un modello, precompilarlo e inviarlo.
- Contano anche gli ospiti. Quasi nessuno entra in WordPress per firmare. Quei trigger sono ricette Everyone: il flusso non dipende da un account.
- Il messaggio può portare la prova. I token passano titolo, firmatario, URL di download sicuro e URL di audit a Slack, all’email o all’azione successiva.
- Il file resta sul tuo sito. Una ricetta cloud manda l’evento sul server di qualcun altro. Questa no. Serve quando il contratto non deve uscire da WordPress solo per applicare un’etichetta o aprire un corso.
Un solo add-on copre tutto questo. Non costruisci un connettore per WooCommerce, poi uno per LearnDash e poi uno per il CRM.
Quando il documento si muove, il sito può seguirlo
Nel costruttore di ricette, WPsigner copre la vita del contratto: creato, inviato, visualizzato, firmato, completato, rifiutato, scaduto, annullato. Ci sono anche trigger per i promemoria, il PDF finito, una copia sul cloud e i pagamenti Stripe (riuscito, fallito, rimborsato). La firma di un utente WordPress connesso è un trigger a parte. Ognuno può osservare un modello o qualsiasi modello.
Basta per coprire ciò che di solito segue una firma:
- Onboarding. Il documento è completato: iscrivi il firmatario al corso LearnDash e etichettalo in FluentCRM.
- Un rifiuto. Firmatario e URL di amministrazione vanno su Slack finché la trattativa è ancora calda.
- Qualcuno l’ha aperto. Il trigger «visualizzato» avvisa che il contratto non è più fermo senza lettura.
- Scaduto o annullato. Il team lo sa lo stesso giorno, non il lunedì.
- Il PDF è pronto. Quando il file firmato viene generato, o quando arriva su Google Drive, Dropbox, OneDrive o S3, invii l’URL a Slack, Teams o via email.
- Pagamento e firma nello stesso flusso. Un pagamento Stripe riuscito può avviare il passo successivo. Un pagamento fallito o rimborsato può avvisare prima di considerare chiuso il contratto.
«Firmato» e «completato» non sono la stessa cosa. Firmato scatta per quel firmatario. Completato scatta quando il documento è finito. Usa firmato se una persona su tre ha firmato e il team deve saperlo. Usa completato se il corso, l’etichetta o il cambio di ruolo devono aspettare tutti.
Quando succede altro, invia il contratto
Le azioni partono da qualsiasi trigger di Automator, non solo da WPsigner. Creare un documento da un modello e precompilarlo. Inviarlo. Sollecitare. Scrivere su Slack, o mandare il promemoria via WhatsApp, SMS, Telegram o Teams. Aggiungere un firmatario, un’etichetta, una scadenza, annullare il documento o rileggere l’elenco dei firmatari nella ricetta.
Le combinazioni che capitano più spesso:
- WooCommerce. L’ordine è pagato. Crei il contratto di servizio da un modello, compili nome ed email di fatturazione e lo invii.
- Moduli. Arriva una voce di Gravity Forms, WPForms o Fluent Forms. Aspetti se serve una revisione, controlli una condizione e poi crei il documento.
- Ciò che hai già automatizzato. Un nuovo membro, un evento di un corso, un cambio di ruolo: se Automator lo vede, quel trigger può creare o inviare un documento WPsigner. WPsigner non ha bisogno di un feed proprio di quel plugin.
I feed nativi di WooCommerce e dei moduli restano. Usali quando il modulo o l’ordine devono solo produrre una richiesta di firma. Usa Automator quando lo stesso flusso ha anche bisogno di un’attesa, una condizione, un’etichetta CRM o un secondo plugin.
Un’attesa, una condizione, un ciclo
Il plugin gratuito di Automator basta per trigger, azioni e token.
Automator Pro aggiunge la diramazione che i team chiedono dopo. Le condizioni possono richiedere uno stato del documento, un modello, un’etichetta o un utente WordPress. I cicli scorrono i firmatari. L’esempio documentato: il documento viene inviato, la ricetta aspetta due giorni e ogni persona che non ha firmato riceve un promemoria WhatsApp.
Nelle impostazioni dell’add-on puoi nascondere gli URL di firma e i valori dei campi nei token e nel registro di Automator.
Che cosa serve
WPsigner Lite o Pro, sullo stesso sito di Uncanny Automator. Filtrare un trigger per modello richiede WPsigner 3.x o successivo. WordPress 5.8+ e PHP 7.4+.
- Attiva Uncanny Automator e WPsigner.
- Installa WPsigner per Uncanny Automator dal portale dell’account, oppure da WPsigner → Addons.
- Apri Automator → Recipes. Usa Everyone, salvo che la ricetta richieda un utente connesso. Aggiungi un trigger o un’azione WPsigner, poi le altre app.
Scheda della directory: automatorplugin.com/integration/wpsigner.
Pagina del prodotto: WPsigner per Uncanny Automator. Trigger, azioni, token e le sei ricette spiegate: documentazione.
WPsigner per Uncanny Automator è un add-on indipendente di WPsigner. Non è affiliato, approvato né sponsorizzato da Uncanny Owl. Uncanny Automator è un marchio del rispettivo titolare.