Applicazione aziendale di grandi dimensioni: i clienti desiderano utilizzare indirizzi e-mail duplicati?

Suggerirei che è un po 'un problema per lo scenario che descrivi.

La mia risposta rimarrà nell'ambito del tuo scenario di un sito di e-learning, supervisori che hanno accesso a e-mail corp e lavoratori che non hanno accesso né hanno bisogno di e-mail corp.

Se lo stickler è reimpostazione della password, fornire meccanismi aggiuntivi per reimpostare la propria password diversa dalla posta elettronica. I sistemi di sfida / risposta sono un modo conveniente per farlo. Consentire agli utenti finali di scegliere tra una vasta serie di domande su dove sarebbero gli unici (in quell'ambiente) che dovrebbero conoscere la risposta.

Se i promemoria relativi alla formazione sono un problema, aggiorna i promemoria al supervisore. Fornire i promemoria sotto forma di rapporto. "Questi utenti sono X giorni dall'essere delinquente sull'addestramento" o "Questi utenti sono a Y giorni dal bisogno di un aggiornamento" o simili. Parte delle funzioni del supervisore è di assicurarsi che i propri dipendenti siano sempre aggiornati sulla formazione. Rendi il promemoria un rapporto che semplifica le loro responsabilità.

Aggiungere la capacità di ricevere messaggi di testo sarebbe un vantaggio. Tenetelo come opt-in solo perché la maggior parte dei lavoratori non riceverà telefoni aziendali. Altrimenti si risentiranno di essere costretti a usare proprietà personali per il lavoro aziendale.

Fornire sistemi di posta elettronica alternativi ignora il fatto che i lavoratori non controllano la posta elettronica al lavoro. Se lo facessero, avrebbero degli account di posta elettronica corp. La sfida da risolvere qui non è quella di fornire loro account di posta elettronica. La sfida consiste nel fornire una misura di autenticazione in cui la posta elettronica non è disponibile per modifiche e promemoria della password.

Non avere un indirizzo e-mail univoco per ciascun dichiarante elimina efficacemente la posta elettronica come opzione di comunicazione e come opzione di identificazione. Tuttavia, questa non è la fine del mondo:

Se non puoi usare l'e-mail per la comunicazione o l'identificazione, non chiedere assolutamente nulla

È giusto, basta saltare l'e-mail del tutto: per quanto riguarda la tua applicazione, è perfettamente inutile.

La mancanza di una e-mail richiede di prendere due decisioni:

1. Come si identifica un dichiarante e
2. Come comunichi con un registrante

La prima domanda richiede a un dichiarante di fornire qualcosa di unico che sia anche esterno alla tua applicazione. Non è possibile chiedere il numero di identificazione rilasciato dal governo, ma un numero di identificazione del dipendente rilasciato dalla società dovrebbe essere perfettamente valido. Questo numero può essere utilizzato per reimpostazioni di password e altre situazioni quando l'identificazione univoca è essenziale. L'utilizzo di un numero di telefono dovrebbe essere un'altra opzione, presupponendo che la società abbia il record del numero di telefono di ciascun dipendente. L'invio di un SMS con un numero di registrazione univoco a un numero di telefono fornito dal dipendente è un altro modo per stabilire l'identità univoca. Se tutto il resto fallisce, puoi stampare una lettera con un numero univoco per ciascun dipendente e inviarla al loro indirizzo di casa o distribuirla ai dipendenti attraverso i loro supervisori.

La comunicazione al dipendente diventa leggermente più problematica, perché il modello "push" dell'e-mail non funziona più. È possibile riprendere il percorso SMS, ma è anche possibile passare al modello "pull", quando si chiede al dipendente di accedere nuovamente dopo un certo periodo di tempo per verificare le comunicazioni destinate a lui o lui. Questo è simile alla strategia adottata da alcuni programmi di preparazione fiscale, quando gli utenti devono controllare dopo 24 ore per vedere se i loro resi sono stati accettati.

Gli indirizzi email dovrebbero essere davvero unici all'interno di un database. La creazione di un indirizzo email è così banale in questi giorni che ognuno dovrebbe avere il suo. Hai dichiarato tutti i motivi per cui hai bisogno di un indirizzo email unico per persona:

Confidentiality

Guarda tutti i siti web che richiedono la registrazione. Se provi a registrarti con un indirizzo già utilizzato, non ti consentono di creare il tuo account. Fai la stessa cosa e andrà tutto bene.

Sicuramente dipende anche dal tipo di informazioni che la tua applicazione invierà via email. Se non si invia alcuna informazione sensibile, la riservatezza non costituirà un problema. Tuttavia, se lo si utilizza per l'accesso, non è possibile avere più persone con la stessa email.

Ma anche se non invii nulla di sensibile, ti consiglio vivamente di richiedere un indirizzo email univoco. Non sai come si evolverà la tua applicazione e potresti voler inviare tali informazioni in futuro. Prendi questa precauzione all'inizio e potresti risparmiare un sacco di mal di testa più tardi.

La mia opinione, in questa situazione possiamo avere due email (colonne Db - PersonalEmail e AdminEmail):

1. Email personale: le query verranno inviate all'utente rispettato.
2. Email di amministrazione / supporto (per chi non dispone di e-mail aziendale personale) - Le richieste verranno inviate all'amministratore di sistema / al team di supporto dell'azienda responsabile degli account utente e che possono anche risolvere le query relative all'utente all'interno dell'organizzazione .

Cheers!

Se hai alcune persone a cui non è permesso avere indirizzi e-mail, lascia che siano tutte condivise. Ad esempio:

[email protected]

O indirizzi generali simili.

Sembra strano che tu non possa creare indirizzi e-mail per le persone, ma posso vedere come alcuni utenti mobili potrebbero non essere in grado di accedere e uscire costantemente dagli account.

Supponendo che stiamo parlando di applicazioni interne in cui gli utenti registrati per un account di posta elettronica gratuito sono inappropriati, se non tutti gli utenti della tua applicazione avranno un indirizzo di posta elettronica aziendale, farei semplicemente l'indirizzo email opzionale. Se un utente ha un indirizzo email aziendale, può inserire quell'indirizzo. Se l'utente non ha un indirizzo email aziendale, non lo farà.

È possibile gestire le reimpostazioni della password in diversi modi senza richiedere un indirizzo email. Puoi consentire a un gestore o amministratore di un utente (ad esempio l'helpdesk) di reimpostare la password di un utente. Presumibilmente, l'utente dovrebbe chiamare il proprio responsabile o l'helpdesk per ottenere la reimpostazione della propria password. Puoi consentire all'utente di reimpostare la propria password online senza email rispondendo ad alcune domande. Queste possono essere le "domande di sicurezza" standard che puoi trovare su vari siti, possono essere cose come un numero di dipendente che è probabile che venga assegnato indipendentemente dal fatto che l'utente ottenga un indirizzo email, può essere informazioni sull'attività dell'account . Le opzioni che utilizzerai dipenderanno, naturalmente, dalla sensibilità delle informazioni memorizzate nel sistema - nel contesto dell'e-learning richiesto, suppongo che il rischio di permettere a qualcuno di compromettere il mio account in modo che possano sedersi attraverso una classe di formazione etica aziendale richiesta è relativamente basso quindi la barra non ha bisogno di essere impostata particolarmente alta.

I promemoria e altre e-mail possono essere inviati all'utente se hanno un indirizzo e-mail e / o il loro supervisore a seconda della natura specifica dell'email. Ciò consente di sopprimere le e-mail non necessarie con le informazioni personali se l'utente non ha un indirizzo e-mail ma ti consente di avvisare il supervisore se un dipendente è in ritardo per un particolare corso di formazione.

Sembra che tu stia confondendo l'identità dell'utente con l'indirizzo email. Se è così, allora insistici. Gli utenti che non hanno un indirizzo email personale possono facilmente ottenerne uno. Oppure puoi facilmente fornirne uno come parte del tuo servizio.

Considerando l'inaffidabilità e la complessità intrinseche di far funzionare la posta elettronica "per tutti", un'alternativa potrebbe essere quella di progettare le proprie interazioni in modo autonomo e non richiedere e-mail per interazioni di routine, o idealmente non necessarie affatto.