Come creare un'app web per annunci interni e sondaggi

Definisci obiettivi e ambito

Prima di scegliere funzionalità o strumenti, chiarisci cosa significa “buono” per la tua app di annunci interni. Un ambito ristretto mantiene la prima release semplice e facilita la dimostrazione del valore.

Cosa stai cercando di risolvere?

La maggior parte dei team costruisce uno strumento di polling per dipendenti e un hub di annunci per motivi pratici:

• Aggiornamenti tempestivi: messaggi critici (cambi di policy, interruzioni, chiusure uffici) devono raggiungere le persone giuste rapidamente.
• Meno messaggi persi: riduci la dipendenza da thread email sparsi o post in chat che si perdono.
• Feedback più veloce: pulse poll rapidi aiutano i leader a individuare problemi in anticipo e adattarsi.

Scrivi i 3 problemi principali che vuoi risolvere, in linguaggio semplice. Se non riesci a spiegarli in una frase, probabilmente l'ambito è troppo ampio.

Definisci gli utenti principali (e cosa serve a ciascuno)

Identifica chi userà il sistema quotidianamente:

• Dipendenti vogliono un feed semplice, call-to-action chiare e la certezza che i loro voti restino privati quando promesso.
• Team lead potrebbero aver bisogno di mirare aggiornamenti ai loro gruppi e fare pulse check leggeri.
• Admin (HR/comms) necessitano controllo di pubblicazione, pianificazione, targeting del pubblico e una dashboard amministrativa per le comunicazioni.

Essere espliciti qui evita decisioni tipo “tutti vogliono tutto” che complicano in seguito il controllo degli accessi.

Cattura i casi d'uso principali

Elenca gli scenari reali che ti aspetti nei primi 60–90 giorni:

• Aggiornamenti di policy che richiedono presa visione
• Allerte di manutenzione con finestre temporali e follow-up
• Inviti a eventi con sondaggi di partecipazione
• Pulse check di una domanda (es.: carico di lavoro, morale)

Se un caso d'uso non si mappa a un risultato misurabile, mettilo in attesa per una versione successiva.

Scegli metriche di successo coerenti con l'obiettivo

Scegli un set piccolo di metriche da rivedere mensilmente:

• View rate per annuncio (per team/sede)
• Vote rate e completion rate per i sondaggi
• Time-to-read (quanto velocemente le persone aprono dopo la pubblicazione)
• Trend sentiment da pulse questions (tracciato nel tempo)

Queste metriche trasformano “l'abbiamo lanciata” in “funziona”, e guideranno decisioni sulle notifiche senza mandare spam agli utenti.

Elenca le funzionalità indispensabili per annunci e sondaggi

Prima di scegliere lo stack tecnologico, definisci chiaramente le funzionalità che rendono l'app utile dal day one. Le comunicazioni interne falliscono spesso perché i post sono difficili da trovare, sono mirati male o i sondaggi non ispirano fiducia.

Annunci: pubblicazione che le persone useranno davvero

Inizia con un editor pulito che supporti rich text (intestazioni, link, elenchi puntati) così i messaggi non diventano muri di testo illeggibili.

Aggiungi allegati (PDF, immagini, policy) con limiti sensati e scansione antivirus. Mantieni lo storage prevedibile permettendo anche l'alternativa “link al file”.

Rendi il contenuto facile da gestire con:

• Categorie (es.: HR, IT, Facilities) e tag opzionali
• Pin per aggiornamenti critici (limita il numero di elementi pinnati)
• Date di scadenza così gli annunci vecchi spariscono dal feed “corrente” ma restano ricercabili

Sondaggi: feedback affidabile con regole chiare

I sondaggi devono essere veloci da rispondere e chiari su cosa succede dopo.

Supporta domande a scelta singola e multipla, e rendi obbligatoria la data di chiusura così i sondaggi non restano aperti per sempre.

Offri due modalità d'identità:

• Anonimo (incoraggia l'onestà; memorizza solo il voto)
• Nominativo (utile per eventi opt-in; mostra chi ha votato)

Decidi anche la visibilità dei risultati per sondaggio: immediata dopo il voto, dopo la chiusura, o solo per gli admin.

Targeting, ricerca e filtri

Una buona app di annunci interni necessita di targeting affinché le persone vedano ciò che conta:

• Azienda intera
• Dipartimenti
• Sedi
• Team (o gruppi di progetto)

Infine, rendi le informazioni recuperabili: ricerca più filtri per categoria, autore, data e tag. Se i dipendenti non trovano l'aggiornamento di policy del mese scorso in 10 secondi, smetteranno di fidarsi del feed intranet.

Pianifica ruoli, permessi e governance

Ruoli chiari e governance mantengono l'app utile e affidabile. Senza di essi, le persone o non riescono a pubblicare ciò che serve, o tutto diventa rumore.

Definisci i ruoli core

Inizia con tre ruoli semplici ed espandi solo quando serve davvero:

• Admin (Comms/HR/IT): creano e modificano annunci, approvano submission, moderano commenti, gestiscono categorie e impostano regole di pubblicazione.
• Manager/Team lead: pubblicano annunci per i loro team (o località/progetti), creano sondaggi di team e vedono trend di partecipazione a livello di team (non le risposte individuali a meno che non sia esplicitamente consentito).
• Dipendenti: leggono annunci, reagiscono, votano nei sondaggi, si iscrivono a categorie e segnalano contenuti inappropriati.

Costruisci un modello di permessi prevedibile

Usa role-based access control (RBAC) come default: i permessi sono assegnati ai ruoli, i ruoli agli utenti. Mantieni la lista dei permessi piccola e basata su azioni (es.: announcement.publish, poll.create, comment.moderate, category.manage).

Aggiungi poi eccezioni con attenzione:

• Permessi scope: “I manager possono postare solo per i loro team.”
• Override temporanei: un ruolo “campaign publisher” limitato nel tempo per un'iniziativa trimestrale.
• Controlli d'emergenza: gli admin possono annullare la pubblicazione e bloccare i commenti immediatamente.

Governance: decidi cosa significa “buono”

Documenta regole leggere che rispecchino come comunica l'azienda:

• Soglie di approvazione (es.: i post company-wide richiedono approvazione admin; i post di team no)
• Proprietà delle categorie (ogni categoria ha un owner nominato e un backup)
• Policy sui commenti (contenuti ammessi, SLA di moderazione, percorso di escalation)
• Auditabilità: registra chi ha creato, modificato, approvato, pubblicato o rimosso contenuti—questo protegge sia i dipendenti sia i moderatori.

Se tieni queste decisioni semplici e visibili, l'app resta credibile e facile da gestire.

Progetta flussi di contenuto e moderazione

Un flusso chiaro mantiene gli annunci tempestivi e affidabili, e impedisce che i sondaggi diventino “chi ha pubblicato questo?”. L'obiettivo è rendere facile la pubblicazione per gli autori, dando però a comms o HR il controllo necessario per mantenere la qualità.

Workflow degli annunci: Draft → Review → Publish

Inizia con un flusso di stato semplice:

• Draft: gli autori possono scrivere, salvare e anteprima. I draft non sono visibili ai dipendenti.
• Review: il contenuto è “pronto” e i revisori vengono notificati. La review si concentra su chiarezza, audience e conformità alla policy.
• Publish: l'annuncio diventa visibile nei canali scelti (company-wide, dipartimento, sede) e inizia il suo programma di notifiche.

Rendi il passaggio fluido: includi una checklist nella schermata di review (categoria corretta, audience impostato, allegati verificati, linguaggio inclusivo).

Regole di approvazione che rispecchiano l'organizzazione

Non tutti i post necessitano di un gatekeeper. Crea regole semplici per categoria e dimensione dell'audience:

• Richiede approvazione: aggiornamenti esecutivi, cambi di policy, legale/compliance, annunci company-wide.
• Approvazione opzionale: aggiornamenti di team, eventi sociali, avvisi in ufficio.

Aggiungi limiti temporali ed escalation così i post non restano bloccati. Esempio: se nessuna decisione arriva in 24 ore, riassegna a un revisore di backup; se ancora in sospeso dopo 48 ore, notifica il proprietario della categoria.

Cronologia delle modifiche e trasparenza

Conserva una history di versione per ogni annuncio:

• Mostra agli impiegati la versione pubblicata più recente di default.
• Visualizza opzionalmente “Modificato il…” con una breve nota di cambiamento.
• Mantieni le versioni precedenti accessibili agli admin per audit e dispute.

Questo evita confusione quando i dettagli (date, luoghi) cambiano dopo la pubblicazione.

Ciclo di vita dei sondaggi: Draft → Open → Closed → Archived

I sondaggi beneficiano di un ciclo di vita rigido:

• Draft: costruisci domande, imposta anonimato, audience e date di apertura/chiusura.
• Open: i voti vengono accettati; le modifiche dovrebbero essere limitate per non spostare gli obiettivi.
• Closed: il voto si interrompe; i risultati vengono calcolati e mostrati in base ai permessi.
• Archived: conservati per reportistica e confronti, ma rimossi dalle liste attive.

Strumenti di moderazione che evitano mal di testa

Anche le app interne necessitano di binari di sicurezza. Fornisci una coda di moderazione per i contenuti segnalati, più controlli di base: nascondi/mostra, blocca commenti (se supportato) e un audit trail ricercabile di chi ha cambiato cosa e quando.

Crea un modello dati semplice

Un modello dati semplice mantiene l'app facile da costruire e da modificare in seguito. Parti con le entità minime necessarie per pubblicare annunci, gestire sondaggi e capire l'engagement—poi aggiungi complessità solo quando serve davvero.

Entità core

Announcement

Minimamente, struttura gli annunci con: title, body, author, audience, tags, status (draft/scheduled/published/archived), publish_at, e expires_at.

Mantieni “audience” flessibile. Invece di hardcodare i dipartimenti, valuta una regola audience che può targettare gruppi (es.: All, Location: Berlin, Team: Support). Ti risparmierà migrazioni future.

Poll

Un sondaggio necessita di: question, options, audience, un flag di anonimato, più open/close dates.

Decidi presto se un sondaggio appartiene a un annuncio (pattern comune) o può essere indipendente. Se prevedi post “annuncio + sondaggio”, un semplice announcement_id su Poll è sufficiente.

Tracciamento dell'engagement (con privacy in mente)

I read receipts sono di solito opzionali. Se li implementi, memorizza un timestamp viewed_at per utente (eventualmente “first_viewed_at” e “last_viewed_at”). Sii esplicito sulla privacy: il tracciamento delle letture può sembrare sorveglianza, quindi limita l'accesso (es.: gli admin vedono aggregati; solo certi ruoli vedono dati per utente) e aggiungi una policy di retention.

Regole di voto

Per i Vote, fai rispettare “un voto per utente per sondaggio” a livello di database (vincolo unico su poll_id + user_id). Se supporti poll multi-select, cambia la regola in “un voto per opzione” (unico su poll_id + user_id + option_id) e conserva un flag su Poll che definisca il comportamento consentito.

Non dimenticare l'auditabilità

Anche un leggero audit log (chi ha pubblicato, modificato, chiuso un sondaggio) aiuta con fiducia e moderazione senza complicare troppo il modello.

Schizza l'esperienza utente (UX) e le schermate

Una buona UX per un'app di annunci interni è per lo più ridurre gli attriti: i dipendenti dovrebbero trovare ciò che conta in pochi secondi, e i comunicatori dovrebbero pubblicare senza pensare al layout.

Navigazione principale

Mantieni la navigazione primaria prevedibile e poco profonda:

• Home feed: vista predefinita con ultimi annunci e sondaggi attivi.
• Categorie: modo semplice per filtrare (es.: HR, IT, Facilities, Leadership). Le categorie devono essere coerenti e limitate.
• Lista sondaggi: pagina dedicata per “aperti”, “in scadenza” e “chiusi”.
• Area admin: visibile solo ai ruoli permessi (draft, scheduling, targeting, moderazione).

Una barra superiore sticky con ricerca e un indicatore “New” aiuta gli utenti di ritorno a vedere subito cosa è cambiato.

Design della card annuncio

Tratta ogni annuncio come una scheda scansabile:

• Titolo chiaro (una riga se possibile)
• Etichetta audience (es.: “Tutto il personale”, “Magazzino”, “Manager”)
• Data/ora di pubblicazione (e “Aggiornato” se modificato)

Aggiungi un'anteprima breve e un “Read more” per evitare muri di testo nel feed.

Schermate sondaggio e regole sui risultati

Il polling deve essere veloce e definitivo:

• Una domanda per schermata (o uno stepper chiaro per domande multiple)
• Opzioni grandi e facilmente selezionabili; mostra una conferma di voto (“Il tuo voto è stato registrato”)
• Definisci regole di visibilità dei risultati: immediati, dopo il voto, alla chiusura, o solo per admin

Basi di accessibilità

Costruisci fiducia facendo le basi: contrasto colore sufficiente, pieno supporto da tastiera (ordine di tab, stati di focus), e tipografia leggibile (lunghezza riga sensata, gerarchia chiara). Queste scelte rendono l'app utilizzabile da tutti, anche su mobile e in ambienti di lavoro rumorosi.

Scegli uno stack tecnologico pratico e l'architettura

Scegli uno stack che il tuo team può rilasciare e mantenere, non la combinazione più alla moda. Annunci interni e sondaggi sono un'app CRUD classica con qualche extra (ruoli, moderazione, notifiche), quindi otterrai i migliori risultati mantenendo l'architettura semplice e prevedibile.

Frontend: ottimizza la velocità di cambiamento

Per la maggior parte dei team, React o Vue sono scelte sicure se già li usate. Se vuoi massima semplicità, le pagine server-rendered (Rails/Django/.NET MVC) possono ridurre le parti in movimento e rendere più semplice ragionare sulle schermate con permessi.

Una buona regola: se non hai bisogno di interazioni altamente dinamiche oltre al voto e al filtraggio di base, il rendering server spesso è sufficiente.

Backend: scegli ciò che sai gestire

Il backend deve rendere semplice autorizzazione, validazione e auditabilità. Buone opzioni includono:

• Node.js (iterazione veloce, grande ecosistema)
• Django (ottimi pattern admin, batterie incluse)
• Ruby on Rails (CRUD produttivo, forti convenzioni)
• .NET (buon fit enterprise, ottimi tool)

Un “modular monolith” (una singola app deployabile con moduli chiari come Announcements, Polls, Admin) di solito batte i microservizi qui.

Se devi consegnare uno strumento interno rapidamente senza ricostruire tutta la pipeline, una piattaforma di generazione come Koder.ai può essere un shortcut pratico: descrivi il feed di annunci, i sondaggi, l'RBAC e la dashboard admin in chat, poi iteri sul frontend React generato e sul backend Go + PostgreSQL. È utile per avere un pilot funzionante davanti a HR/comms velocemente, mantenendo l'opzione di esportare il codice sorgente dopo.

Dati + API: tienili noiosi (e documentati)

Usa PostgreSQL per dati relazionali come utenti, ruoli, annunci, domande sondaggi, opzioni e voti. Aggiungi Redis solo se serve caching, rate limiting o coordinazione di job in background.

Per l'API, REST funziona bene con endpoint prevedibili e leggibili; GraphQL aiuta se prevedi molti client diversi e esigenze complesse di dati per schermata. In ogni caso, documentalo e mantieni naming coerente così frontend e strumenti admin non divergono.

Gestisci autenticazione, sicurezza e privacy

Le decisioni di sicurezza sono difficili da cambiare dopo, quindi vale la pena fissare poche regole chiare prima di costruire le funzionalità.

Autenticazione: usa SSO quando possibile

Se l'azienda usa già un identity provider (Okta, Azure AD, Google Workspace), preferisci SSO via OIDC (la più comune) o SAML. Riduce il rischio delle password, rende l'offboarding automatico e permette alle persone di accedere con l'account già in uso.

Se SSO non è disponibile, usa email/password con protezioni standard: hashing robusto, rate limiting, blocchi account e MFA opzionale. Mantieni la procedura “ho dimenticato la password” semplice e sicura.

Autorizzazione: RBAC su ogni endpoint

Definisci ruoli presto (es.: Employee, Editor, Comms Admin, IT Admin). Poi applica role-based access control (RBAC) ovunque—non solo nell'interfaccia. Ogni endpoint API e azione admin deve verificare i permessi (create announcement, publish, pin, create poll, view results, export data, manage users, ecc.).

Regola pratica: se un utente non può fare qualcosa chiamando direttamente l'API, non può farlo dall'app.

Privacy dei dati: raccogli meno, offri anonimato

I sondaggi spesso toccano temi sensibili. Supporta sondaggi anonimi dove le risposte sono memorizzate senza identificatori utente, e sii esplicito su cosa significa “anonimo” (es.: gli admin non vedono chi ha votato).

Minimizza i dati personali: solitamente servono solo nome, email, dipartimento e ruolo (prelevati dall'SSO se possibile). Imposta regole di retention (es.: elimina risposte raw dopo 12 mesi, conserva solo conteggi aggregati).

Log di audit: rendi tracciabili le azioni admin

Conserva un audit trail per eventi chiave: chi ha pubblicato/modificato/eliminato un annuncio, chi ha chiuso un sondaggio prima, chi ha cambiato permessi e quando. Rendi i log ricercabili nell'area admin e proteggili da modifiche.

Aggiungi notifiche senza fare spam

Le notifiche sono utili solo quando sono tempestive e rispettose. Per annunci e sondaggi interni mira a “alto segnale, basso rumore”: notifica ciò a cui l'utente si è iscritto, riassumi il resto e smetti una volta che ha agito.

Usa canali misti (e fai guadagnare ognuno il suo posto)

Notifiche in-app funzionano meglio per la consapevolezza mentre qualcuno è già nello strumento. Invia una notifica piccola e rimovibile quando c'è un nuovo annuncio in una categoria che l'utente segue (es.: “IT Updates” o “HR Policies”). Collega direttamente all'elemento e mostra la categoria per valutare la rilevanza.

Digest email prevengono l'overload inbox. Offri riepiloghi giornalieri/settimanali che raggruppano nuovi annunci e sondaggi aperti, invece di una mail per post. Includi azioni rapide (“View”, “Vote”) per ridurre l'attrito.

Promemoria che rispettano l'attenzione

I promemoria ai sondaggi devono essere intenzionali, non spam automatico:

• Reminders: sollecita i non responder poco prima della chiusura del sondaggio, con limiti rigidi (es.: max 1–2 promemoria per sondaggio).
• Interrompi i promemoria subito dopo che l'utente ha votato.
• Evita promemoria per sondaggi “FYI” dove la partecipazione non è richiesta.

Lascia che gli utenti controllino il rumore

Dai alle persone controlli chiari per tarare la rilevanza:

• Preferenze: gli utenti scelgono le categorie da seguire e la frequenza delle notifiche.
• Opzioni “mute” (silenzia una categoria per 30 giorni, silenzia tutto durante le ferie).
• Supporta orari silenziosi per email e alert simili a push.

Una pagina semplice /settings/notifications facilmente comprensibile farà più per l'adozione di qualsiasi algoritmo intelligente.

Costruisci report e analytics

Il reporting trasforma la tua app da bacheca a strumento di comunicazione migliorabile. Mantieni l'analisi focalizzata sulle decisioni: cosa hanno visto le persone, con cosa si sono coinvolte e dove i messaggi non arrivano.

Performance degli annunci

Nella dashboard admin, inizia con una semplice “scheda” per ogni annuncio:

• Views (visualizzatori unici e visualizzazioni totali)
• Reazioni (conteggi e tipi principali)
• Conteggio commenti (solo se i commenti sono abilitati)
• Read rate nel tempo (es.: % visualizzato in 24h, 72h, 7d)

Mostra queste metriche con contesto: data di pubblicazione, segmento audience e canale (homepage, email, bridge Slack/Teams se presente). Aiuta a confrontare annunci simili senza indovinare.

Metriche dei sondaggi utili

Per lo strumento di polling concentra su partecipazione e chiarezza:

• Participation rate: voti ÷ audience eleggibile
• Distribuzione opzioni: conteggi e percentuali per opzione
• Trend nel tempo: partecipazione e risultati per settimana/mese (utile per pulse ricorrenti)

Per i sondaggi anonimi, mantieni i risultati aggregati e evita insight su piccoli gruppi che potrebbero rivelare identità.

Report segmentati (con privacy)

I report segmentati (per dipartimento o sede) possono migliorare il targeting, ma aggiungi guardrail:

• Mostra breakdown solo quando la dimensione del segmento supera una soglia minima (es.: 10+ risposte).
• Per sondaggi anonimi, non esporre mai dati per utente—memorizza e riporta solo aggregati.

Esportazioni e condivisione

L'export CSV è utile per admin che devono informare la leadership o combinare risultati con altri strumenti. Mantieni le esportazioni permissionate via RBAC, e registra le azioni di export nei log di audit per chiarezza di governance.

Testa, distribuisci e monitora l'app

Rilasciare un'app di annunci interni non è solo “funziona?” ma “funziona per le persone giuste, con la giusta visibilità, ogni volta?”. Una checklist breve e ripetibile ti salverà da post o sondaggi indirizzati male.

Checklist di test (cosa verificare prima del rollout)

Concentrati su scenari reali, non solo percorsi felici:

• Permessi e RBAC: admin possono pubblicare/modificare; moderatori approvano; dipendenti non vedono draft o post riservati.
• Regole di targeting: annunci e sondaggi appaiono solo per le sedi, dipartimenti o gruppi previsti.
• Sondaggi anonimi: verifica che l'anonimato sia preservato in esportazioni, analytics e audit log (nessun identificatore accidentale).
• Casi limite: annunci scaduti, sondaggi modificati a metà corsa, utenti con ruoli multipli, allegati cancellati e fusi orari.

Controlli di qualità dei contenuti

Considera i contenuti come parte del prodotto:

• Link rotti e problemi di formattazione (soprattutto su mobile)
• Limiti dimensione/tipo allegati e comportamento quando vengono superati
• Basi di accessibilità: intestazioni leggibili, etichette pulsanti chiare, contrasto sufficiente

Deployment: staging → produzione

Usa un ambiente di staging con dati realistici e account di test. Per il rollout in produzione, pianifica:

• Una breve finestra di manutenzione (se necessaria) e un chiaro piano di rollback
• Step di migrazione dati (seed ruoli, gruppi di default, annunci iniziali)
• Un “soft launch” a un dipartimento prima dell'accesso company-wide

Se usi un approccio gestito di generazione/app (es.: generare l'app in Koder.ai), applica la stessa disciplina: staging prima, tracciamento chiaro dei cambiamenti e possibilità di rollback (snapshot/rollback utili quando iteri velocemente).

Monitoraggio post-lancio

Imposta monitoraggio leggero dal giorno uno:

• Error tracking per eccezioni frontend e backend
• Controlli uptime su endpoint core (login, caricamento feed, invio voto)
• Metriche di performance base: tempo di caricamento pagina, latenza API e query DB lente

Regola pratica: monitora il percorso utente, non solo i server.

Favorisci l'adozione e mantieni l'app utile nel tempo

Anche un'app ben costruita fallisce se le persone non si fidano, non la ricordano o non vedono il valore nell'aprirla. L'adozione riguarda meno il “giorno del lancio” e più creare abitudini: post prevedibili, ownership chiara e formazione leggera.

Piano di lancio: inizia piccolo, poi scala

Inizia con un gruppo pilota che rappresenti ruoli diversi (HR/comms, manager, staff frontline). Usalo per 2–3 settimane con una checklist chiara: trovano gli annunci velocemente, votano in un minuto e capiscono cosa ci si aspetta da loro?

Raccogli feedback in due modi: un breve sondaggio in-app dopo azioni chiave (postare, votare) e un check-in settimanale di 15 minuti con i champion del pilot. Poi lancia per fasi (es.: un dipartimento per volta), usando ciò che hai imparato per aggiornare categorie, default e notifiche.

Formazione che rispetta il tempo delle persone

Mantieni il materiale di formazione corto e pratico:

• Guide di una pagina con screenshot (“Come votare”, “Come iscriversi a una categoria”)
• Un modello “come postare”: titolo, sommario, audience, call-to-action, data di fine
• Uno script breve per manager nelle riunioni di team (“Ecco dove trovare gli aggiornamenti e cosa ci aspettiamo che facciate”)

Governance: rendi visibile la proprietà

L'adozione cresce quando i contenuti sono coerenti. Definisci linee guida per i post (tono, lunghezza, quando usare sondaggi vs annunci), assegna owner di categoria (HR, IT, Facilities) e stabilisci una cadenza (es.: roundup settimanale + post urgenti quando necessario). Nell'area admin mostra i nomi dei proprietari di categoria così le persone sanno chi contattare.

Itera usando segnali reali d'uso

Considera l'app come un prodotto: mantieni un backlog, prioritizza in base a dati (views, completion rate dei sondaggi, time-to-read) e feedback qualitativo, e rilascia piccoli miglioramenti regolarmente. Se i post “All-company” vengono ignorati, prova un targeting più stretto; se i sondaggi hanno bassa completazione, accorciali o chiarisci scopo e data di chiusura.