Portal de clients: com definir-lo abans de desenvolupar-lo

Quan un client demana per correu electrònic un document que ja ha rebut, truca per saber l’estat d’una sol·licitud o envia la mateixa informació a diverses persones, el problema no acostuma a ser la manca de canals. Acostuma a faltar un lloc clar on cada client pugui consultar i gestionar allò que li correspon.

Un portal de clients pot resoldre aquesta situació, però no convé començar per una llista de pantalles o per la tecnologia. En aquesta guia veuràs què cal decidir abans: l’objectiu que ha de complir, què cal incloure en la primera versió, quines dades i responsables necessites, quin tipus de solució encaixa i com validar-la. En acabar, podràs decidir si necessites un portal i preparar una conversa de projecte amb menys incògnites.

Resultat esperat

El resultat no és simplement una zona privada amb usuari i contrasenya. És un espai on el client pot completar accions concretes sense dependre d’intercanvis manuals innecessaris.

Segons la teva activitat, aquestes accions poden consistir a consultar l’estat d’una comanda o servei, descarregar documentació, enviar una sol·licitud, actualitzar dades, revisar pressupostos o comunicar una incidència. No cal que totes hi siguin des de l’inici.

Un portal està ben plantejat quan pots respondre amb claredat aquestes preguntes:

• Quines gestions podrà resoldre el client per si mateix?
• Quina informació veurà i quina informació en quedarà fora?
• Quina persona de la teva empresa revisarà cada sol·licitud o actualització?
• Quins sistemes han d’intercanviar dades amb el portal?
• Com comprovaràs que el recorregut funciona abans d’obrir-lo a tots els clients?

Pas 1: defineix l’objectiu del portal de clients

Objectiu: identificar el problema operatiu o comercial que ha de resoldre el portal.

Acció: comença per un procés repetit, no per la idea genèrica de «millorar l’atenció al client». Descriu què passa ara, qui hi intervé i què hauria de poder fer el client d’una altra manera.

Per exemple, un objectiu podria ser: «permetre que els clients consultin la documentació associada al seu servei sense demanar-la per correu electrònic». Un altre: «recollir sol·licituds de canvi amb les dades necessàries perquè l’equip les pugui revisar». Són objectius diferents i requereixen funcionalitats diferents.

Formula l’objectiu amb una acció observable:

El client ha de poder consultar, enviar, aprovar, descarregar o actualitzar alguna cosa concreta.

Evita objectius massa oberts, com ara «oferir una experiència més completa» o «centralitzar-ho tot». No ajuden a decidir què cal construir ni quan es pot considerar que el portal està llest.

Comprovació: acaba aquest pas si pots completar aquesta frase: «El portal permetrà a [tipus de client] [acció concreta] per evitar o millorar [situació actual]».

Pas 2: delimita l’abast de la primera versió

Objectiu: decidir què necessita el portal per complir la seva funció inicial i què pot esperar.

Acció: reuneix les funcionalitats possibles i classifica-les per prioritat. Una primera versió es pot centrar en una tasca principal i unes quantes accions de suport. Afegir de cop totes les necessitats detectades acostuma a dificultar la revisió, el manteniment i l’explicació del sistema.

Pots ordenar les funcionalitats en quatre grups:

• Imprescindibles: sense elles no es compleix l’objectiu definit.
• Desitjables: aporten comoditat o valor, però es poden incorporar més endavant.
• Futures: tenen sentit, tot i que encara falten dades, responsables o una necessitat estable.
• Fora d’abast: no pertanyen al portal o requereixen un projecte separat.

Imagina, com a exemple hipotètic, una empresa que comparteix documentació de projectes amb els seus clients. En una primera versió, l’accés als documents, l’organització per projecte i les notificacions bàsiques podrien ser imprescindibles. Una àrea de missatgeria, informes personalitzats o una aplicació mòbil podrien quedar per a una fase posterior si no són necessaris per resoldre la consulta documental.

També convé fixar límits explícits. Si el portal mostra l’estat d’una sol·licitud, defineix quins estats existeixen i qui els actualitza. Si permet enviar formularis, concreta els camps, el destinatari i què passa quan falta informació.

Comprovació: cada funcionalitat inclosa ha de tenir un usuari, un motiu i una manera de comprovar que funciona. Si no els pots explicar, aquesta funcionalitat encara no està preparada per formar part de l’abast.

Pas 3: organitza dades, permisos i responsables

Objectiu: evitar que el portal exposi informació incorrecta, incompleta o accessible per a qui no correspon.

Acció: fes un inventari senzill de la informació que entrarà, es consultarà o es modificarà. Després, defineix qui pot veure cada tipus de dada i qui se’n responsabilitza del manteniment.

No n’hi ha prou de diferenciar entre «client» i «administrador». En alguns negocis hi pot haver diversos contactes per client, responsables amb accés limitat, personal intern que prepara documents i persones que aproven canvis. Els permisos han de reflectir aquestes diferències reals.

Per a cada bloc d’informació, aclareix:

• quina dada és i d’on prové;
• qui la pot consultar;
• qui la pot modificar;
• qui revisa els canvis quan calgui;
• què passa si falta, està desactualitzada o conté un error.

Les connexions amb altres eines també requereixen detall. Dir que el portal es connectarà amb un programa de gestió no descriu el flux. Cal decidir quines dades s’intercanvien, quan s’actualitzen, quin sistema conserva la referència principal i com es tractaran els errors de connexió.

La gestió dels accessos i de les dades s’ha de revisar amb les persones responsables de la teva operativa i, quan correspongui, amb assessorament especialitzat. Un desenvolupament tècnic no substitueix aquestes decisions.

Comprovació: pots dibuixar un recorregut senzill des que una dada es crea fins que el client la consulta o la modifica, incloent-hi la persona que hi intervé si hi ha una revisió manual.

Pas 4: tria la solució a partir de l’abast

Objectiu: seleccionar una solució que respongui al procés definit i que puguis mantenir.

Acció: compara alternatives després de fixar l’objectiu, les funcionalitats, els usuaris i les dades. Una eina estàndard pot encaixar si el procés segueix un patró conegut i n’accepta les limitacions. Una solució a mida pot tenir sentit quan necessites regles específiques, permisos particulars, integracions o una evolució que una opció estàndard no cobreix de manera raonable.

La decisió no depèn només que el portal tingui bon aspecte. Revisa també:

• l’accés des de mòbil i ordinador;
• la facilitat per administrar continguts, sol·licituds o usuaris;
• les integracions necessàries;
• la possibilitat d’afegir funcionalitats més endavant;
• les dependències de serveis externs;
• el manteniment d’accessos, dades i actualitzacions.

Evita decidir per etiquetes com «app» o «plataforma». Un portal de clients pot ser una aplicació web accessible des del navegador, i no necessita convertir-se en una aplicació mòbil per complir la seva funció.

Si els teus requisits inclouen fluxos propis, rols, informació connectada amb altres sistemes o una gestió interna específica, el projecte pot encaixar en l’àmbit de les aplicacions i programari a mida. L’anàlisi prèvia permet determinar quina solució és proporcional al problema, sense donar-la per feta abans d’hora.

Comprovació: pots explicar per què la solució triada permet cobrir l’abast imprescindible, quines limitacions acceptes i quines decisions es reserven per a una evolució posterior.

Pas 5: valida abans d’obrir el portal a tots els clients

Objectiu: comprovar que els recorreguts principals funcionen per als clients i l’equip intern.

Acció: defineix criteris d’acceptació abans de considerar acabat el desenvolupament. Un criteri útil descriu una situació inicial, una acció i el resultat esperat.

Per exemple: «Quan un client autoritzat inicia sessió i accedeix al seu projecte, pot descarregar els documents que li corresponen. Si no té accés a un document, el portal no l’ha de mostrar». Aquest tipus de definició permet revisar un comportament concret, en lloc de limitar-se a valorar si «sembla acabat».

Prova els recorreguts més importants amb perfils i casos diferents: dades completes i incompletes, usuaris amb permisos diferents, sol·licituds amb errors i situacions en què ha d’intervenir una persona interna. També convé validar qui atendrà les incidències i com es comunicaran els canvis rellevants als clients.

La validació no s’acaba en publicar el portal. Els usos reals poden revelar dubtes, passos innecessaris o responsabilitats que no estaven clares. Registra aquestes observacions per decidir què cal ajustar, sense convertir cada petició aïllada en una nova funcionalitat automàtica.

Comprovació: abans d’obrir el portal, els responsables poden confirmar que les accions prioritàries, els permisos i els escenaris d’error responen al que s’ha acordat.

Errors d’execució que convé evitar

• Construir una zona privada sense una acció principal. Si el client hi entra però no sap què hi pot resoldre, el portal afegeix un canal sense ordenar el procés.
• Incloure totes les idees en la primera versió. Barrejar allò necessari amb allò desitjable fa més difícil fixar prioritats i validar el resultat.
• Definir els permisos de manera genèrica. «El client veu les seves dades» no concreta què passa quan hi ha diversos contactes, projectes o nivells d’accés.
• Anomenar una integració sense descriure el flux. Cal decidir quina informació es comparteix, qui la manté i què passa si deixa d’actualitzar-se.
• Oblidar l’equip que administrarà el portal. Cada formulari, document, estat o avís ha de tenir una persona responsable.
• Validar només la pantalla principal. Els errors acostumen a aparèixer en permisos, dades incompletes, canvis d’estat i excepcions del procés.

Un portal de clients val la pena quan dona autonomia en una gestió concreta i manté el control intern sobre dades, permisos i seguiment. Si ja tens identificat el procés que vols ordenar, pots explicar el teu projecte de portal de clients a AVSISTEC per valorar l’abast i les incerteses que convé resoldre abans de desenvolupar-lo.