Progettare app clienti e app per la forza vendita secondo i compiti

Progetterei i percorsi di un’app in base a compiti e permessi. Un cliente aziendale ordina per la propria impresa; una commerciale lavora con più clienti assegnati. Shopify documenta associazione aziendale e riordino negli account B2B. L’app mobile di vendita di Microsoft offre accesso da record recenti e riunioni.

Un confronto presso un grossista di cartoleria

Un grossista fittizio prevede accessi mobili per acquisti e venditori sul territorio. Il confronto descrive i compiti previsti:

L’elenco comune dei prodotti può essere simile. Per i venditori sul territorio, la scelta ripetuta di un altro cliente si aggiunge al percorso.

La bozza mantiene il collegamento al cliente

Nell’esempio, il passaggio a un altro cliente deve lasciare la bozza esistente chiaramente associata all’account originale. L’interfaccia deve mostrare il collegamento all’apertura e al salvataggio. Un semplice cambio della vista iniziale non deve trasferire senza avviso la bozza a un’altra azienda. Il gruppo definisce anche quali note di consulenza restano interne e quali informazioni possono vedere i clienti.

I permessi vanno verificati sul server; nascondere campi non basta. La vista prevista per ruolo deve quindi essere controllata insieme agli accessi ai dati consentiti.

Riutilizzare i componenti comuni in modo mirato

Ricerca prodotti, schede e controllo prezzi possono condividere una base tecnica. Se il venditore prepara solo occasionalmente una bozza d’ordine per clienti assegnati, può essere adatta anche un’app comune con aree di lavoro chiaramente separate. La sola differenza di ruolo non rende obbligatorie app distinte.

Nel prototipo verifichi il riordino per la propria azienda e la bozza per un cliente assegnato. Osservi soprattutto se l’associazione all’azienda corretta resta comprensibile cambiando cliente e salvando.

Fonti

• Shopify — B2B customer accounts

• Microsoft — Manage records in the Sales mobile app

• OWASP — Authorization