Updates added per @blunders request
2014-04-30 More Updates added as I thought of a couple of more items
I once had an SFDC system with only 7 users so here is my experience (after all was setup and users trained)
Starting with your example tasks ...
- Salesforce required changes : 0 hours - about the only time I ever ran across this was when SFDC dropped support for IE6 and IE6 was part of the standard desktop image installed by IT
- Testing upgrades : 0 hours - even on much larger SFDC instances, I would not formally test SFDC upgrades in the PROD environment. The whole point of the cloud solution is that SFDC is responsible for maintaining backward compatibility - you are paying for this 'feature'. If anything, testing SFDC upgrades on pre-releases usually is more frustrating than revealing as it exposes more SFDC bugs than errors in the specific org. Obviously on more mission critical orgs, more rigorous testing makes sense but for 7-10 users - only if you want to bill some hours
- Backups - 10 minutes - I set up a weekly export to backup everything to CSV and saved it off to a network drive. I never once had to do a restore because the users had messed up the database so badly that we needed to recover.
- System monitoring - 0 to epsilon hours; again, this is SFDC's job and if the org goes down, so do thousands of other orgs. The SFDC OPs team have plenty of motivation to get things back up. I would send an email to my users with links to trust.salesforce.com/status + instance moniker so they could track progress themselves
- Bulk data loading - varies - could be 0 to 1-2 hours per week if users are forcing the admin to upload data without troubling themselves to learn the wizards (or if the org is complex enough without good validation rules that user's can't be trusted to do this)
- User admin - 0-2hrs -- This could be the common - 'I'm locked out because I forgot my password' to the more tedious (Claude has left the company, can you reassign all his accounts/oppos/whatever to Claudine except for the Illinois accounts which go to Frobisher) requests
That said, on my 7 person org, I could go months without a peep from the user community on any of the items you mentioned
as for other 'keep the lights on' tasks not related to adding features or constructing reports, the items were rare and episodic:
- Dealing with the renewal SFDC subscription (e.g. justifying the system expense to Finance; seeing that the PO got issued; making sure the invoice got paid). In the aforementioned org, because the cost of 7 users p.a. was so low, there were interdepartmental battles over who would pay for it (ironic eh?) so this could get time consuming
- Responding to queries as to whether SFDC was secure; what our Business Systems Continuity strategy was if SFDC was down (answer: wait until it comes back up)
- Email deliverability issues - From time to time, some user would complain that they weren't getting email or email they sent to someone wasn't received. I was reminded of this today when on a different org, we ran into non-delivery of email sent from yahoo.com users due to Yahoo DMARC policy change as documented here in SFDC KB.
Bottom line, you can invest very little time in keeping the lights on if the system you built from the get go is well tested, has easy-to-locate reports, has good validation rules, and is as intuitive as possible. In the aforementioned org, users were plenty happy with the classic SFDC interface and saw no need to even go to Chatter or the new UI - I'm reminded of the systems I see at my dentist - still a Win95-based UI; or at my auto insurance carrier's underwriter's desk - screen-scraped 3270 system --- so you really can get away with very little background maintenance.