Inizia Ora
Cosa succede dopo la consegna: garanzia, aggiornamenti, modifiche e supporto.
L'assistenza Squalionline parte da un canale chiaro e da una descrizione verificabile del problema. Il team identifica impatto e causa, distingue bug, configurazione, servizio terzo o nuova richiesta e interviene secondo priorità e condizioni del progetto. Per richieste generali è disponibile [email protected]; progetti strutturati possono avere un referente dedicato.
Il riferimento generale indicato per l'assistenza Squalionline è [email protected]. Per progetti strutturati possono essere previsti anche referente, canale o procedura dedicati, così la richiesta arriva direttamente al team che conosce il sistema.
La garanzia copre ciò che viene definito nell'offerta o nel contratto. Quando viene indicata una garanzia a vita, va intesa come disponibilità a correggere anomalie imputabili al lavoro consegnato nel perimetro concordato, non come manutenzione illimitata di qualsiasi modifica futura o servizio esterno.
Non è normalmente una correzione in garanzia una nuova funzione, un cambio di design richiesto dopo l'approvazione, una modifica a processi non previsti, un problema causato da credenziali o configurazioni cambiate dal cliente, oppure una rottura introdotta da API, plugin o servizi terzi. Questi casi vengono analizzati e preventivati se necessario.
Per segnalare un bug invia la pagina o funzione interessata, utente/ruolo, passaggi esatti per riprodurlo, risultato atteso e risultato ottenuto. Screenshot o video aiutano, così come data e ora. Evita di condividere password: se servono accessi temporanei, vengono gestiti con una procedura sicura.
Servono contesto, URL o modulo, account o ruolo coinvolto, passaggi per riprodurre il problema, messaggio di errore, data/ora e materiale visivo se utile. Per integrazioni è importante indicare anche sistema esterno e record interessato. Informazioni precise riducono il tempo necessario per arrivare alla causa.
La priorità dipende da impatto e urgenza: sito o sistema completamente indisponibile, perdita di dati o blocco di un processo critico vengono trattati diversamente da un difetto estetico o una richiesta evolutiva. Per progetti strutturati possono essere definiti livelli e tempi di presa in carico specifici.
Se il sito non è raggiungibile verifichiamo DNS, dominio, certificato, hosting, deploy, rete e dipendenze esterne. Se l'infrastruttura rientra nel perimetro di assistenza applichiamo la procedura di ripristino prevista e controlliamo i log. Un problema del registrar o provider viene gestito insieme al relativo supporto.
Prima verifichiamo se il problema riguarda credenziali, permessi, sessione, rete o indisponibilità del servizio. Se coinvolge un singolo utente interveniamo sull'account; se è generale controlliamo infrastruttura e log. L'obiettivo è ripristinare l'operatività senza aggirare controlli di sicurezza con account condivisi o password temporanee non tracciate.
Usa la procedura di reset password prevista. Il sistema non deve recuperare o inviare la vecchia password in chiaro. Se l'accesso dipende da Google, Microsoft o altro identity provider, si segue il loro recupero ufficiale. L'assistenza può aiutare a verificare account e permessi senza chiedere credenziali personali.
Verifichiamo se l'account è disattivato, il ruolo è cambiato, la password è scaduta o l'autenticazione esterna ha un problema. Un amministratore autorizzato può ripristinare l'accesso secondo la procedura, mantenendo log e principio del minimo privilegio invece di assegnare permessi eccessivi per risolvere velocemente.
Un nuovo amministratore viene creato o promosso da un account già autorizzato, verificando identità e necessità del ruolo. Dopo il passaggio è buona pratica rimuovere o ridurre i privilegi dell'amministratore precedente e aggiornare recovery, MFA e contatti operativi.
Se un'API esterna cambia analizziamo documentazione, endpoint, autenticazione e dati modificati, testiamo l'adeguamento in staging e aggiorniamo il connettore. Poiché il cambiamento nasce dal fornitore, l'intervento può essere distinto dalla garanzia sul codice originario e viene valutato in base all'impatto.
Se un plugin o servizio terzo cambia, verifichiamo compatibilità e alternative. Un aggiornamento può richiedere configurazione, sostituzione o sviluppo aggiuntivo. Documentare dipendenze e versioni permette di capire rapidamente se il problema è nel progetto Squalionline o nel componente esterno.
Sì. Possiamo aggiornare un progetto anche dopo anni, ma prima facciamo un audit di framework, dipendenze, hosting, sicurezza e qualità del codice. Se la base è ancora sostenibile interveniamo per moduli; se il debito tecnico è troppo alto proponiamo una migrazione graduale invece di accumulare patch.
Sì. Nuovi moduli possono essere aggiunti quando l'architettura lo consente. Prima definiamo dati condivisi, permessi, dipendenze e come il modulo entra nel workflow esistente. La modularità evita di duplicare anagrafiche e regole già presenti nel sistema.
Sì. Possiamo aggiungere integrazioni verificando prima API, autorizzazioni, limiti e ownership del dato. Il nuovo collegamento viene testato con error handling e log e documentato, così il sistema rimane comprensibile anche quando nel tempo aumenta il numero di servizi collegati.
Sì. Il design può evolvere dopo la consegna, da piccoli componenti a un redesign più ampio. Prima verifichiamo impatto su responsive, accessibilità, CMS e conversioni. Se esiste un design system, la modifica viene riportata nei componenti condivisi per evitare pagine incoerenti.
Sì. Possiamo creare nuove landing mantenendo design system, analytics e integrazione con campagne e CRM. Ogni landing deve però avere un intento reale e contenuto distinto; non consigliamo di moltiplicare pagine quasi identiche solo per sostituire una keyword.
Sì. Possiamo formare nuovi dipendenti con sessioni per ruolo, ambiente di prova e guide operative. L'obiettivo è insegnare le attività che devono realmente svolgere e le procedure di sicurezza, non fare una dimostrazione generica dell'intero software.
Sì. Possiamo creare manuali, FAQ, video o knowledge base operative per funzioni e ruoli. La documentazione viene mantenuta vicina al processo e aggiornata quando cambiano schermate o procedure, così non diventa un PDF dimenticato che descrive una versione vecchia del sistema.
Sì. Nel go-live possiamo affiancare utenti e responsabili, monitorare errori e integrazioni, raccogliere un elenco unico di anomalie e supportare le prime operazioni reali. Per sistemi complessi è utile partire con un gruppo pilota o una sede, poi estendere dopo la stabilizzazione.
Durante l'assistenza i backup seguono il piano dell'infrastruttura: frequenza, retention, copie separate e test di ripristino. Prima di modifiche ad alto impatto possono essere creati snapshot o backup aggiuntivi. È importante sapere anche chi è responsabile del backup quando l'hosting è gestito da un provider o dal cliente.
Sì. Possiamo eseguire un controllo di sicurezza sul perimetro concordato: accessi, ruoli, dipendenze, configurazioni, segreti, backup, logging e componenti esposti. Un audit applicativo non sostituisce automaticamente penetration test o certificazioni specialistiche, che possono richiedere attività dedicate.
Sì. Un audit del software esistente analizza architettura, codice quando disponibile, database, dipendenze, integrazioni, sicurezza, performance, UX e capacità di evolvere. Il risultato deve indicare problemi prioritari, rischio e opzioni: correggere, integrare, migrare o rifare per fasi.
Sì. Possiamo prendere in carico un progetto creato da altri dopo una fase di audit. Servono accessi a hosting, dominio, repository, database e servizi collegati. Prima di promettere modifiche verifichiamo qualità e licenze; se mancano codice o credenziali essenziali, definiamo un piano di recupero o migrazione.
Sì, se il codice è disponibile e legalmente utilizzabile. Prima eseguiamo audit su architettura, dipendenze, test e sicurezza e riproduciamo il problema. Se la correzione è sostenibile interveniamo; se il codice è troppo fragile spieghiamo perché una riscrittura parziale o migrazione riduce il costo futuro.
Si confrontano costo e rischio della correzione con quelli di una ricostruzione. Si valutano qualità del codice, architettura, test, sicurezza, documentazione, dipendenze, prestazioni e capacità di evolvere. Se correggere significa continuare a pagare debito tecnico senza eliminare il problema, un rifacimento graduale può essere più conveniente.
Sì. La migrazione da un vecchio fornitore viene pianificata inventariando dominio, DNS, hosting, email, database, repository, analytics, API e licenze. Recuperiamo gli accessi tramite procedure ufficiali, creiamo backup e prepariamo il nuovo ambiente prima di cambiare traffico, così il passaggio non dipende da un'unica giornata critica.
Si parte dall'inventario degli asset: dominio e registrar, DNS, hosting, repository, database, email, analytics, Search Console, account cloud, API e licenze. Il cliente deve recuperare o trasferire gli accessi tramite procedure ufficiali. Prima della migrazione si eseguono backup e si documenta ciò che dipende dal vecchio fornitore per evitare interruzioni.
Raccontaci la situazione: ti diciamo se e come possiamo aiutarti.
Parla con il team