I would advise your customer to not do that.  While it generally good practice to regularly accept changes into your development workspace, there are periods of time (often a few hours, but sometimes stretching to a couple days) where you do not want to accept any incoming changes (such as when you are deep into a serious debugging session).  RTC makes it very easy for developers to accept changes, easy enough that decent developers will do it frequently.  Automating the process is unlikely to save time and is more likely to lead to frustrated developers.

It's certainly possible but the benefits might not be worth the trouble you create for yourself and your developers.

You run into potential problems of sandboxes out of sync with repository workspaces, losing unresolved changes, and scalability in deployment or maintenance.

Piotr's solution would have issues deploying to all your developers. The script would also need to run with the developer's credentials in order to run the accept on the workspace. The alternative is running with an admin account. If the script runs on a different system for all developers, you'll cause out of sync issues to your developers.

Josh's solution would run on a build engine and not the developer's system. This would cause out of sync issues and could mean every developer would have to reload out of sync projects every morning. The build only runs on one workspace at a time and post-build deliver only works on one stream/workspace. You run into scalability issues creating a build for every developer.