Thinking in terms of 'hours of internet usage' is too narrow. A user might regularly use a particular set of tools and web apps every day as part of their job, but that doesn't mean they'll be familiar with patterns common to other sorts of applications. Conversely, a less experienced user might have enough domain knowledge or familiarity with a paper analogy to understand your interface anyway. And even if a user is extremely experienced, that won't help much if your application employs radically different models of handling a problem than they've seen anywhere else. 'Technical competence' is more complex than 'low to high'.
What's more, a user's competence doesn't determine the amount of time they're willing to put into an application. Novice users with a strong investment in your product may be more tolerant of barriers. They won't be as happy as you'd like, but they will convert (and that's the point of improving UX, after all). As a corollary, a competent user might still be sceptical about the advantages of your product, and therefore less likely to invest extended effort. An old-school salesman might be a dab hand with Excel, but he's not convinced yet that your social media tool is going to get him many leads.
So, instead of asking, 'How experienced is the user on a scale from 1 - 10?', try asking the following:
- what does my user think they can get from this application, and how do they suspect they might get it?
- what domain knowledge does my user have? Have they used similar products? Different products that employ similar models?
- what investment does my user have in completing his work on the application? How can I bring my users the lion's share of these benefits as early as possible?
To answer these questions, you might use interviews, personas or (if all else fails) your own domain knowledge. But these will serve you far better than categories like 'novice' and 'expert'.