What I realize more and more is that the end-users wants to be In Control. This applies especially with new developed applications that automates some of their work. By default users are skeptic. The application have to earn their trust. The more they get the feeling they are not in control, the less trust and the less acceptance of your newly developed product.
Only when the product doesn’t automate or replace existing work, an employee is likely to accept the application more easily. But still you first have to prove it and earn the users trust.
So what can you conclude from this:
At the moment you are working on a project that will automate a part of the users work, try to learn how he does that work, and don’t take away his flexibility. It´s allright that the application makes decisions and perform actions that he normally did, but certainly in the first releases, let him be the one that controls the final action.
For example when it comes to communication with customers. Originally he had to write and send the emails by hand. A desired functionality of the application is to do this automatically. A good approach to fully reach this functionality is to split it in several releases.
In the first release make sure the user can see all the emails that are about to be send, let him edit the emails if he likes to, and let him push the button that finally sends the mail. The user can see what the application is doing, and will build some trust with it.
So in the second release you extend this functionality with a scheduler and a “do send” / “do not send” checker. The user have to “check” the emails for “do send” and they are send automatically on a configurable time. The user can see if the scheduler works and that the emails are send correctly. So the trust in the application increases more.
In a third release all the emails are set default to “do send”, and the scheduler sends them every half our (or something). The user doesn’t really have to look to the emails anymore, because he now trusts the functionality of the application. He still has the possibility to go and check the emails, alter them, deny them or disable / configure the scheduler.
If you do it this way, the user feels he is In Control. So the acceptance of the new product is much higher then if you fully automate the sending of email, but nobody had the ability to check or prevent what is being send.
Even if a system is flawless and everything is working exactly as designed, there will always be exceptions in the process. And if the users don’t feel they can do anything about it, they get the feeling they are not in control. It is very likely that your new application won’t be accepted.
Just make your users feel they are In Control!