There are lots of questions that need to be answered here:
- Are you using a vcs?
- What is your branching strategy?
- Can you deploy using a single button?
- Do you have automated tests?
- When do you run the tests?
- Do you have any continuous integration?
- What happens with your team while the job is on the Staging area? Are you working on something else? Or just waiting?
- What happens with the QA team while the UAT part is going on?
- How long it takes you to deploy?
- Does deployment mean that your user cannot work on the system?
- Do you have a database? Can you undo a deployment on your database?
The basics of what you are doing is fine, mostly because of that luxurious trait of having a fully closed specification (never happened to me). But the basics don't make your life easier, nor provide the best value for your company.
I am supposing you have a vcs. Which branching strategy are you using? Those strategies will change based on the vcs. I would choose a different branching strategy if I am using Subversion/TFS Source Control or if I am using distributed ones like git or hg.
Have tests(unit, integration, requirement), and make sure that you can run them automatically. Tests should be run on a CI environment that goes between the dev and the staging environments. Any bug encountered by the QA team should become an automated test where possible (depending on your UI technology that could not be always possible). These actions will: reduce the time spend on "Staging", reduce the number of bugs that appear, reduce the number of regression errors that will appear.
The CI environment should automatically compile and run all the tests (it could be well possible that you want to run unit tests all the time, but integration tests only at one specific point of the day). This action will provide your team with assurance that either you are not breaking anything or that you will know pretty much immediatly. Tools for CI? Jenkins, Team City, TFS, ...
At some point I was working on a team on which a deployment of our application meant usually a two hour manual process that needed all users to be logged out. We managed to improve it, though still manual, to less than 5 minutes with only a restart for the users if there was no database change. If there was a database change, it still required half hour of the users being out. But the time I left the company we were looking at using tools (Octopus on this case) to make it even easier and a green/blue strategy on our database to eliminate completely downtime (except for the restart of the client terminals).
I would completely separate the staging environment for internal QA from the staging environment for UAT. My previous experience is that is very messy to have them together.
I would have a prelive environment just to test the deployment on the exact same conditions as there are in live. I had suprises before because our system was depending on some library or OS patch that was present on all stages but Live.
Which then will mean that there is another question, can your IT team replicate the setup of live? If they cannot they should be working on it. The provisioning of a machine/environment should be completely automated once you have the hardware.
You can always improve your process. At the beginning you usually can take some big strides, later one, is more fine tuning. You should ask yourself (and your team) the question that you have posted every month.