URL shortener white-label per agenzie: una guida completa all'acquisto

La maggior parte delle agenzie si rivolge a uno URL shortener white-label per la stessa ragione superficiale: i clienti se ne accorgono quando i tuoi link abbreviati dicono bit.ly o s.elido.me. Le ragioni più profonde sono di solito il margine di fatturazione e la difendibilità dell'audit. Il team IT di un cliente che chiede "dove vanno i dati di click?" merita una risposta più chiara di "un fornitore statunitense che rivendo tramite intermediario."

Questa guida è scritta per direttori operativi e titolari di agenzia che stanno valutando opzioni white-label - non per sviluppatori che vogliono costruire infrastrutture di link da zero. L'obiettivo è darti un framework per confrontare ciò che le diverse piattaforme consegnano realmente a ogni layer di branding, le domande reali da porre ai vendor e una procedura guidata concreta di come funziona la configurazione degli account reseller.

Cosa significa realmente "white-label", layer per layer#

Il termine viene usato in modo approssimativo. I vendor che offrono custom branded domain si definiscono white-label. Lo fanno anche i vendor che ti permettono di mettere un logo sul dashboard. Non sono la stessa cosa, e la differenza è importante per come prezzi e gestisci il servizio per i clienti.

Ci sono sei layer distinti. Non tutte le piattaforme li implementano tutti.

Layer 1: Custom redirect domain#

Il significato più comune. Invece che i redirect passino attraverso il dominio della piattaforma (bit.ly/xyz), passano attraverso un dominio che controlli (go.tuaagenzia.com/xyz o go.clientebrand.com/xyz). Questo è il white-label minimo indispensabile per la maggior parte dei casi d'uso delle agenzie - rimuove il nome della piattaforma da ogni link che i tuoi clienti condividono.

L'implementazione richiede un record CNAME DNS dal tuo sottodominio all'edge della piattaforma e un certificato TLS automatico per quel hostname. Tutti i principali shortener gestiscono questo. La variabile è su scala multi-tenant: quando gestisci venti domini cliente invece di uno, la piattaforma supporta CNAME wildcard (*.links.tuaagenzia.com), o devi aggiungere un record DNS per cliente?

Layer 2: Dashboard branding#

L'interfaccia amministrativa della piattaforma porta il tuo logo, il nome del brand e il colore primario invece di quelli della piattaforma. I clienti che accedono per gestire i loro link vedono il tuo brand, non quello della piattaforma. Alcune piattaforme ti permettono anche di sostituire il titolo della scheda del browser e il favicon.

Questo layer è ciò che rende il servizio presentabile quando i clienti interagiscono direttamente con esso. Senza di esso, un cliente che clicca su "Visualizza dashboard" dalla tua pagina di report atterra su una pagina brandizzata Bitly o Rebrandly, e l'accordo diventa trasparente.

Layer 3: Custom email sender#

Le reimpostazioni della password, i report sui click, gli avvisi di scadenza dei link e le email di invito vengono inviati da [email protected] invece che dal dominio della piattaforma. Questo viene spesso trascurato finché un cliente non chiede perché riceve email da un fornitore con cui non ha concordato di lavorare. Un mittente email personalizzato influisce anche sulla recapitabilità: la reputazione del dominio per le email transazionali risale al dominio mittente.

Layer 4: Custom portal subdomain#

Il dashboard stesso vive su un hostname che controlli - links.tuaagenzia.com - piuttosto che su app.qualchepiattaforma.com. Questo richiede che la piattaforma instradi l'hostname links.tuaagenzia.com al contesto del tenant del tuo workspace, emetta un certificato TLS per esso e scopra le sessioni utente di conseguenza. È un'implementazione notevolmente più complessa di un custom redirect domain, e meno piattaforme la forniscono.

Layer 5: Gestione dei sub-account#

Puoi creare workspace separati per ogni cliente, ciascuno con il proprio dominio, libreria di link, analisi e membri del team - tutti gestiti da un singolo account genitore reseller. Questo è il layer che separa l'infrastruttura rivendibile dall'accesso self-service rebrandizzato.

Senza la gestione dei sub-account, il white-label si rompe operativamente su scala. O dai a tutti i clienti accesso a un workspace condiviso (il che significa che possono vedere i link e i dati degli altri) o mantieni account separati per piattaforma per ogni cliente (il che significa relazioni di fatturazione separate e nessuna vista consolidata per il tuo team).

Layer 6: Fatturazione reseller e reporting sull'utilizzo#

Tu paghi la piattaforma a un tasso wholesale; fatturi i clienti al tuo tasso. La superficie di fatturazione della piattaforma è invisibile ai tuoi clienti. Il reporting sull'utilizzo è scoperto per ogni workspace cliente così puoi giustificare le fatture senza esporre i dati degli altri clienti.

Questo layer tipicamente vive dietro una conversazione di vendita enterprise. Poche piattaforme pubblicano i prezzi reseller sulle loro pagine pubbliche.

---

Lo spettro dal Layer 1 al Layer 6 è ciò che distingue una piattaforma che supporta i link brandizzati da una genuinamente costruita per la rivendita da parte delle agenzie.

Come si confrontano i principali vendor#

Bitly Enterprise#

Bitly supporta custom domain nei piani a pagamento. Il dashboard branding non è una funzionalità pubblicata - l'interfaccia di Bitly è brandizzata Bitly per tutti i tier. L'invio email personalizzato dal tuo dominio non fa parte del prodotto standard. L'integrazione SSO di Bitly si trova dietro il tier Premium ($199/mese secondo la pagina dei prezzi consultata il 2026-05-11 - verifica prima di citarla a un cliente). Non c'è voce white-label nella matrice delle funzionalità o nel foglio del prodotto enterprise.

Per la maggior parte delle agenzie che valutano un'operazione di rivendita, Bitly non è una scelta pratica. Il riconoscimento del brand di bit.ly nei link è un problema noto, non risolto, anche in Enterprise. Bitly è una scelta forte per i team di marketing interni; non è stato progettato per scomparire dietro il brand di qualcun altro.

Rebrandly Pro / Business#

Rebrandly ha una voce white-label contrassegnata come limitata nei confronti di funzionalità indipendenti. Il prodotto ha una solida UX per i link brandizzati e supporta i custom domain in ogni tier a pagamento. Il dashboard è brandizzato Rebrandly; il branding personalizzato per workspace non è una funzionalità documentata pubblicamente. Il mittente email personalizzato non è documentato nelle pagine delle funzionalità pubbliche. La loro struttura dei prezzi (Essentials $11 / Professional $32 / Growth $99 secondo la pagina dei prezzi consultata il 2026-05-11) non include un tier reseller sulla pagina pubblica.

I punti di forza di Rebrandly sono le sue integrazioni di automazione no-code (Zapier, Make, Workato) e il suo flusso di configurazione per singolo dominio curato. Per un'agenzia che vuole fornire ai clienti un custom branded domain pulito senza un'operazione di rivendita complessa, Rebrandly funziona per il Layer 1 e parzialmente per il Layer 2. Per i Layer 4–6, dovresti negoziare un accordo enterprise personalizzato.

Short.io#

Short.io ha il supporto white-label esplicito come funzionalità del prodotto. Il loro piano Business ($90/mese secondo la loro pagina dei prezzi consultata il 2026-05-11) include le impostazioni white-label. I custom domain sono supportati dal piano Personal in su; la matrice delle funzionalità mostra il white-label come disponibile nel tier Business.

Il white-label di Short.io sembra coprire l'esperienza del dashboard brandizzato e i custom domain. Cinque custom domain sono disponibili anche nel tier gratuito, che è insolitamente generoso per la configurazione del Layer 1. La piattaforma è con sede negli USA; la residenza dei dati per i clienti UE richiede una revisione della Transfer Impact Assessment.

Elido Business#

Il white-label di Elido copre tutti e sei i layer descritti sopra, e l'implementazione è documentata nel codebase piuttosto che come affermazione di marketing. Le funzionalità specificamente rilasciate:

• Custom redirect domain con verifica DNS automatizzata e emissione del TLS automatico on-demand per ogni hostname tenant (verificato dal nostro servizio di validazione dei domini)
• CNAME wildcard (*.links.tuaagenzia.com) nel piano Business per la copertura dei sottodomini multi-client senza voci DNS per cliente
• Dashboard branding per workspace - campi brand_name, logo_url (URL HTTPS o data URL base64, max ~512 KB), primary_color (hex o oklch), email_from_name e portal_hostname, esposti tramite PUT /v1/workspaces/{id}/branding; gated al tier Business a livello di tier
• Routing del portal subdomain - portal_hostname instrada un hostname personalizzato (es. links.acme.com) al workspace corretto; GET /v1/portal/lookup risolve un header host a un workspace_id, usato sia dal TLS automatico on-demand che dal middleware Next.js del dashboard per scoprire le sessioni
• Account reseller - POST /v1/workspaces/{id}/reseller crea un account reseller con company_name, contact_email, custom_domain e branding_config; POST /v1/workspaces/{id}/reseller/workspaces crea un sub-workspace collegato all'account reseller; gli endpoint di lista e rimozione seguono lo stesso pattern
• Residenza dei dati EU-first - la regione UE come primaria, nessun egress dal SEE a meno che il workspace non opti esplicitamente per USA Est o Asia-Pacifico; DPA con obblighi dell'Articolo 28 incluso nel contratto standard

La mutazione del branding è vincolata al piano Business a livello API; il server restituisce 402 Payment Required se il workspace è su un tier inferiore. I dati di branding esistenti sopravvivono a un downgrade e sono recuperabili al re-upgrade senza reinserirli.

La pagina delle soluzioni per le agenzie è il riferimento orientato ai team di acquisto per questo set di funzionalità.

---

La tabella seguente riassume quanto documentato pubblicamente o verificabile per ogni vendor. Le celle contrassegnate come "non documentato" indicano che la funzionalità è assente dalle pagine dei prezzi pubbliche, dalle pagine delle funzionalità e dai documenti DPA pubblicati - potrebbe esistere dietro negoziazione enterprise.

Layer	Bitly	Rebrandly	Short.io	Elido
Custom redirect domain	Piani a pagamento	Piani a pagamento	Tutti i piani a pagamento (5 sul gratuito)	Business
Dashboard branding	Non documentato	Non documentato	Business	Business
Custom email sender	Non documentato	Non documentato	Non documentato	Business
Portal subdomain	Non documentato	Non documentato	Non documentato	Business
Gestione sub-account	Non documentato	Non documentato	Parziale	Business (reseller API)
Residenza dei dati UE	Primario USA	Primario USA	Primario USA	Default regione UE

Prezzi dalle pagine pubbliche consultate il 2026-05-11. Verifica prima del procurement.

Caso d'uso agenzia: una procedura guidata concreta#

La seguente è la procedura di configurazione reseller su Elido. La sequenza è la stessa che tu la faccia tramite il dashboard o l'API; il percorso API è mostrato perché le agenzie che operano su scala vorranno automatizzarlo per ogni onboarding di nuovo cliente.

1. Abilita il reseller sul tuo workspace agenzia#

La tua agenzia ha un singolo workspace genitore nel piano Business. Registri un account reseller una volta:

curl -X POST https://api.elido.app/v1/workspaces/{your_workspace_id}/reseller \
  -H "Authorization: Bearer $ELIDO_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "company_name": "Acme Digital Agency",
    "contact_email": "[email protected]",
    "custom_domain": "links.acmedigital.example",
    "branding_config": {}
  }'

La risposta include un reseller_account_id. Conservalo.

2. Crea un workspace cliente#

Quando onboardi un nuovo cliente, crea un sub-workspace collegato al tuo account reseller:

curl -X POST https://api.elido.app/v1/workspaces/{your_workspace_id}/reseller/workspaces \
  -H "Authorization: Bearer $ELIDO_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "workspace_id": 99201,
    "label": "Client: TechCorp EMEA"
  }'

Il workspace_id qui è il workspace del cliente, creato attraverso il normale flusso di provisioning del workspace. Il label è il tuo riferimento interno - i clienti non lo vedono.

3. Configura il DNS per il custom domain del cliente#

Il cliente vuole che i suoi redirect passino attraverso go.techcorp-emea.example. Aggiungi due record DNS nel pannello del loro provider DNS:

go.techcorp-emea.example   CNAME   b.elido.me.
_elido-verify.go.techcorp-emea.example   TXT   "ws_<their_workspace_token>"

Il token di verifica appare nelle Impostazioni > Custom Domain del loro workspace. Una volta che il nostro servizio di validazione dei domini rileva il record TXT, contrassegna il dominio come verificato e un certificato TLS viene emesso automaticamente alla prossima richiesta.

4. Configura il branding per workspace#

Imposta il branding del workspace del cliente dal tuo account reseller:

curl -X PUT https://api.elido.app/v1/workspaces/{client_workspace_id}/branding \
  -H "Authorization: Bearer $ELIDO_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "brand_name": "TechCorp Links",
    "logo_url": "https://assets.techcorp-emea.example/logo-dark.png",
    "primary_color": "#0a2463",
    "email_from_name": "TechCorp Links",
    "portal_hostname": "links.techcorp-emea.example",
    "enabled": true
  }'

Il portal_hostname qui è il sottodominio del dashboard personalizzato. Deve essere univoco tra tutti i workspace nella piattaforma - viene restituito un 409 Conflict se un altro workspace lo rivendica già. Una volta impostato, links.techcorp-emea.example instrada direttamente al dashboard di gestione link di TechCorp, brandizzato sotto la loro identità.

5. Il cliente riceve link sul loro dominio, accede al loro portale#

Da questo momento, il team di TechCorp accede su links.techcorp-emea.example, crea link che si risolvono sotto go.techcorp-emea.example e riceve notifiche email da TechCorp Links. Il nome di Elido non appare in nessuno di questi punti di contatto.

Per una spiegazione dettagliata della meccanica DNS e del ciclo di vita del certificato TLS, la guida ai custom domain copre il quadro operativo completo inclusi i record CAA, la latenza di propagazione e cosa succede quando l'amministratore DNS di un cliente rimuove il CNAME durante una campagna.

Considerazioni sul modello di prezzo per la rivendita delle agenzie#

L'economia della rivendita della gestione dei link appare diversa a seconda di come funziona il modello di fatturazione della piattaforma.

I modelli per limite-di-link (struttura di Rebrandly) addebitano in base al numero di URL abbreviati attivi nel tuo account. Per un'agenzia che gestisce molti clienti con librerie di link moderate, il limite può diventare il vincolo prima che lo faccia il volume di click. I link accumulati attivi di ogni cliente contribuiscono al totale, e un cliente con molte campagne che crea 500 nuovi link al mese raggiunge le soglie del tier più velocemente di un cliente che genera 500.000 click attraverso dieci link evergreen.

I modelli per volume di click (struttura di Elido per il piano Business) addebitano in base al volume di redirect in tutta l'organizzazione, con un eccedenza misurata per click oltre la soglia del piano. Il vincolo è il traffico, non l'inventario. Le agenzie che gestiscono molti clienti con profili di traffico moderati possono gestire una grande libreria di link combinata senza pressione di tier derivante dal solo numero di link.

Nessun modello è universalmente più economico. Il punto di incrocio dipende dal mix dei tuoi clienti. L'analisi corretta: prendi il tuo numero totale di link attivi tra tutti i clienti e il tuo volume di click mensile totale tra tutti i clienti, esegui entrambi rispetto al modello di prezzo di ogni vendor per il tier che copre quel volume e confronta il costo annualizzato. Poi considera il margine reseller che intendi applicare.

Un punto di partenza pratico per il markup reseller: la maggior parte delle agenzie che operano servizi software per conto dei clienti applica un markup del 20-40% sopra il proprio costo. Con una piattaforma che ti fattura mensilmente e ti consente di fatturare i clienti indipendentemente, il tuo margine sulla componente di gestione dei link è semplice da calcolare. Le piattaforme che richiedono account individuali rivolti ai clienti, o che fatturano per workspace senza una vista reseller consolidata, rendono questo più difficile da gestire in modo pulito.

La visibilità della fatturazione basata sull'utilizzo vale la pena di richiedere esplicitamente. Vuoi poter eseguire un report sull'utilizzo per cliente a fine mese senza esportare dati manualmente. Le analisi con scope per workspace di Elido ti permettono di estrarre il volume di click per sub-workspace tramite l'API; Short.io e Rebrandly hanno analisi a livello di workspace, anche se la fatturazione consolidata in modalità reseller è una funzionalità da verificare sui piani attuali.

Aspetto della conformità: rivendita a PMI UE#

Quando rivendi servizi di gestione link a clienti con sede nell'UE, diventi un responsabile del trattamento nella catena. I tuoi clienti sono titolari del trattamento dei dati di click dei loro utenti finali. La piattaforma è un sub-responsabile. Questo accordo è disciplinato dall'Articolo 28 del GDPR - la relazione responsabile-sub-responsabile richiede che il contratto con la piattaforma includa obblighi vincolanti come sub-responsabile del trattamento, e che tu abbia obblighi corrispondenti nei confronti dei tuoi clienti.

Gli obblighi pratici per un'agenzia che rivende a PMI UE:

Il contratto con il tuo cliente necessita di un DPA. L'accordo con ogni cliente deve includere un accordo per il trattamento dei dati che copra i dati di click dei link come dati personali. I DPA con template standard sono accettabili; le clausole chiave sono le categorie di dati trattati, la divulgazione dei sub-responsabili e le misure di sicurezza. Non usare un template DPA che copra solo il tuo trattamento interno - deve trasmettere gli obblighi del sub-responsabile a valle alla piattaforma che stai usando.

Divulgazione dei sub-responsabili. Il tuo DPA dovrebbe elencare la piattaforma su cui sei costruito come sub-responsabile. I tuoi clienti hanno il diritto di sapere chi tratta i dati dei loro utenti finali. Se stai usando una piattaforma con sede negli USA, questo attiva un requisito di Transfer Impact Assessment per molti clienti UE di settori regolamentati. Se stai usando una piattaforma con sede nell'UE, il requisito TIA tipicamente non viene attivato.

Conferma della residenza dei dati. Se il procurement del tuo cliente richiede la residenza contrattuale dei dati - "tutti i dati personali rimangono nel SEE" - la tua scelta di piattaforma determina se puoi accettarlo. Bitly, Rebrandly e Short.io sono primari negli USA e richiederebbero documentazione di trasferimento transfrontaliero basata su SCC. L'infrastruttura con default nella regione UE di Elido significa che puoi impegnarti contrattualmente sulla residenza nel SEE senza accordi personalizzati.

SLA di notifica delle violazioni. L'Articolo 33 del GDPR richiede ai titolari di notificare la loro autorità di controllo entro 72 ore dall'essere venuti a conoscenza di una violazione di dati personali. Come responsabile nella catena, devi notificare i tuoi clienti (i titolari) "senza ingiustificato ritardo" dopo essere venuto a conoscenza di una violazione. Il SLA di notifica degli incidenti di sicurezza della tua piattaforma dovrebbe essere inferiore a 72 ore - verifica questo nel DPA o nell'addendum sulla sicurezza.

Registro delle attività di trattamento. Ai sensi dell'Articolo 30, devi mantenere un Registro delle Attività di Trattamento (RAT) come responsabile. Questo dovrebbe includere i tuoi sub-responsabili. Tenere aggiornata la documentazione del DPA della piattaforma è il modo per mantenere questo senza sforzo manuale.

Il post sul GDPR per gli URL shortener ha il quadro legale completo se vuoi le citazioni degli articoli per la revisione del tuo DPO. Per il procurement specifico sulla residenza UE, la trust page di Elido su /trust elenca i sub-responsabili (infrastruttura UE, recapito e-mail UE, pagamenti e fornitori CDN) e i termini del DPA.

Checklist di migrazione: spostare un portafoglio clienti di agenzia#

Se stai spostando i clienti da Bitly o Rebrandly a una piattaforma white-label, la migrazione coinvolge tre percorsi paralleli: inventario dei link, DNS e comunicazione con i clienti.

Fase di inventario (prima di cambiare qualsiasi cosa):

• Esporta tutti i link brevi per ogni cliente dalla piattaforma attuale. Da Bitly: Impostazioni > Esporta. Da Rebrandly: export CSV del workspace. Ogni riga dovrebbe avere l'URL breve, l'URL di destinazione, il custom domain (se presente), lo slug, i tag e la data di creazione.
• Documenta quali clienti sono su custom domain rispetto a domini di piattaforma. I clienti su domini di piattaforma hanno più lavoro davanti: hanno bisogno di un nuovo dominio o sottodominio configurato prima della migrazione.
• Controlla i link senza custom domain che sono incorporati in materiali stampati, footer email o pagine esterne che non puoi aggiornare. Questi sono i tuoi link ad alto rischio - si romperanno se il vecchio account di piattaforma viene chiuso. Segnalali separatamente.

DNS e preservazione dei redirect:

• Per i clienti su custom domain: stai reindirizzando il loro CNAME dalla vecchia piattaforma a quella nuova. Lo slug e la destinazione possono essere importati prima che il DNS si propaghi, quindi non c'è finestra di 404 se tempi il cutover DNS dopo l'importazione massiva.
• Riduci il TTL del CNAME a 300 secondi almeno 48 ore prima del cutover per minimizzare la latenza di propagazione nel giorno dello switch.
• Importa i record dei link sulla nuova piattaforma usando l'API di importazione massiva (POST /v1/links/bulk su Elido) prima di toccare il DNS. Verifica che un nuovo redirect si risolva correttamente sulla nuova piattaforma usando l'API prima di toccare il DNS.
• Effettua il cutover DNS in un momento di basso traffico. La maggior parte dei link delle agenzie vede meno traffico nelle mattinate dei giorni feriali nel fuso orario di destinazione.
• Mantieni il vecchio account della piattaforma attivo per almeno 14 giorni dopo il cutover per catturare eventuali straggler del resolver DNS. Se i link sulla vecchia piattaforma ora puntano alla tua nuova configurazione, questa finestra può essere più breve.

Comunicazione con i clienti:

• Notifica i clienti almeno una settimana prima del cutover DNS, inquadrando il cambiamento come un miglioramento dell'infrastruttura. Includi data e ora del cambiamento pianificato.
• Dopo il cutover, invia una conferma con il nuovo URL del dashboard se stai cambiando i portal hostname.
• Alcuni clienti vorranno verificare che i loro link funzionino ancora dopo il cutover. Dai loro un modo semplice per farlo - una lista di cinque o dieci link rappresentativi che possono testare da soli.

Analisi storiche:

• La cronologia dei click non migra tra le piattaforme. Le analisi dal giorno del cutover in poi sono nel nuovo sistema. Se i clienti hanno bisogno di dati storici per scopi di reporting, esportali dalla vecchia piattaforma prima che l'account venga chiuso e conservali nei tuoi archivi o forniscili direttamente al cliente.
• Sia Bitly che Rebrandly esportano conteggi di click aggregati nei loro export CSV. Gli eventi di click grezzi (timestamp individuale, paese, dispositivo, referrer per click) tipicamente non sono esportabili da nessuna delle due piattaforme.

Il playbook di migrazione da Bitly copre le meccaniche specifiche di Bitly in modo più dettagliato, inclusa la paginazione API per grandi inventari di link e la tempistica del sovrapposizione DNS.

Cosa chiedere a qualsiasi vendor prima di firmare#

Questa lista è breve di proposito. Puoi leggere le pagine delle funzionalità; queste sono le domande a cui non puoi rispondere dal sito di marketing.

L'API supporta il provisioning di sub-workspace reseller? Chiedi l'endpoint, non solo "sì". Testalo in un account di prova prima di firmare. Un'operazione white-label che richiede ticket di supporto della piattaforma manuale per ogni onboarding cliente non scala oltre circa dieci clienti.

Dove vivono i dati di click dei miei clienti e puoi impegnarti contrattualmente? Le assicurazioni verbali non sopravvivono alla revisione del procurement. La risposta dovrebbe essere una giurisdizione (la regione UE, USA Est, ecc.) e dovrebbe apparire nel DPA che firmi.

Qual è il tuo SLA di notifica degli incidenti di sicurezza ai clienti? La risposta è importante per il tuo obbligo ai sensi dell'Articolo 33 del GDPR. Meno di 24 ore è lo standard per le piattaforme che prendono questo sul serio.

Cosa succede al branding e ai link dei miei clienti se effettuo un downgrade o me ne vado? Chiedi esplicitamente se i dati di branding per workspace vengono preservati in caso di downgrade (così non perdi la configurazione se perdi un pagamento) e quali sono le opzioni di esportazione dei dati. Alcune piattaforme eliminano i dati del workspace alla cancellazione dell'account con breve preavviso.

Posso impostare l'indirizzo di fatturazione e i dettagli della fattura sulla mia agenzia, non su singoli account cliente? Se i clienti possono vedere l'interfaccia di fatturazione della piattaforma, l'accordo di rivendita diventa trasparente. La fatturazione consolidata a un singolo account agenzia con dettaglio sull'utilizzo per workspace è ciò di cui hai bisogno.

---

La pagina solutions/agencies è dove le funzionalità specifiche per agenzia di Elido sono documentate per i team di acquisto. La pagina dei prezzi ha i dettagli del tier attuale e la tabella comparativa dei piani.

Per domande sulla configurazione dell'account reseller, i termini del DPA o la migrazione di un portafoglio clienti, il team di vendita è raggiungibile dalla pagina dei contatti.

Correlati sul blog#

• Residenza dei dati UE per gli strumenti di marketing: cosa chiede realmente il tuo DPO
• SCIM e SSO per gli strumenti di marketing: cosa chiede realmente l'IT enterprise
• Configura link brevi brandizzati: scegli un dominio, pubblica in un pomeriggio
• Schrems II e pixel di tracciamento: dove ti lascia il DPF nel 2026