Una landing B2B con dentro il prodotto vero

Problema

La pagina Mappo del sito parlava al viaggiatore, ma il servizio si vende alle agenzie di viaggio, non a chi parte. Serviva una pagina rivolta al titolare di agenzia, che mostrasse il prodotto finito invece di raccontarlo.

Con un vincolo: il servizio è white label, quindi nelle schermate dell’app il nome del fornitore non deve comparire mai.

Materiali

Download diretto, un clic, nessun form.

• Blueprint: landing B2B white label
  PDF
  Traccia in nove sezioni per costruire una pagina che vende una tecnologia a chi la rivenderà col proprio marchio.
• Snippet: mockup telefono con demo live
  PDF
  HTML, CSS e JS per incorporare un’app navigabile dentro una cornice smartphone, con scala calcolata a runtime.
• Checklist: demo live dentro un mockup
  PDF
  I controlli da fare prima di considerare finita una pagina con demo incorporata.

Metodo

1. Backup prima di sostituire. Il contenuto precedente è stato duplicato in una bozza e salvato in locale. La pagina vecchia non è stata cancellata, è stata messa da parte.
2. Scrivere la struttura prima della grafica. Nove sezioni in ordine fisso, ognuna con un compito preciso. I testi completi prima di aprire qualsiasi editor. La traccia è nel primo materiale.
3. Mostrare il prodotto, non gli screenshot. L’app di esempio è stata pubblicata su una pagina dedicata, in noindex e fuori dal menu, incapsulata in un iframe isolato per evitare che il CSS del tema ne rompesse il layout.
4. Incorporare la demo nel mockup. L’iframe gira a dimensione reale di telefono e viene rimpicciolito con una scala calcolata a runtime dalla larghezza del contenitore: così combacia su qualunque schermo. Codice completo nel secondo materiale.
5. Verificare a 390px veri. Non rimpicciolendo la finestra del desktop, che può lasciare invariato il viewport reale, ma misurando contenitore e contenuto e confrontando i valori.

Limiti

• Prova eseguita a settembre 2026 su WordPress con Elementor, tema custom, hosting con cache di pagina. Su altre combinazioni i punti critici cambiano.
• Su questo tipo di pagina Elementor rende il contenuto salvato nei propri dati, non nel contenuto classico: le modifiche fatte via API al contenuto non si vedono online. Va usato l’editor.
• La demo incorporata è una sola app di esempio, e i due mockup mostrano la stessa schermata iniziale. Un carosello di schermate diverse sarebbe più efficace.
• L’iframe carica un’applicazione intera dentro la pagina. C’è il caricamento differito, ma su connessioni lente resta un peso da tenere d’occhio.
• Nessun dato di conversione: la pagina è online da poco. Quello che si può dire riguarda il metodo, non i risultati commerciali.

Correzioni

Cosa è cambiato dopo la prima esecuzione.

• Screenshot statici → demo navigabile. La generazione automatica degli screenshot non è andata a buon fine per un limite dell’ambiente. Invece di aggirarlo, è stata incorporata l’app vera: il risultato è migliore dell’idea di partenza.
• Scala fissa → scala calcolata. Le scale scritte a mano per ogni breakpoint andavano fuori sincrono col contenitore e tagliavano bordo destro e inferiore.
• Iframe compresso dal tema. Una regola globale del tema limitava la larghezza dell’iframe prima dello scaling: l’app veniva disegnata a metà larghezza e sbagliava i propri breakpoint. Risolto neutralizzando la regola.
• Due tag di chiusura di troppo. Chiudevano in anticipo il contenitore principale: tutte le sezioni sotto la prima perdevano margini e spaziature. Sembrava un problema estetico, era strutturale.
• Sezione «chi c’è dietro» rimossa. Non aggiungeva niente alla decisione di chi legge.
• Etichetta del pulsante. Da «richiedi una demo» a «guarda la demo», che porta all’app a tutto schermo: meno attrito, la richiesta arriva dopo.