you need some way of priortising the workload that comes in and identifying the things that need to be actioned right now as opposed to those that dont affect the business and can be done "Business as Usual".

To make a decision you would need to have at least 2 criteria to come to a finding. In this case the decision making process is started by examining the Impact and Urgency and the outcome is the priority.

priority 1 needs to be addressed now as it is business impacting
priority 2 as soon a possible as it has the potential to become business impact or is business impacting but has some form of a workaround
priority 3 Business as usual - individuals or small numbers of people affected that is not considered business impacting._________________Mark O'Loughlin
ITSM / ITIL Consultant

I would say the main benefit to the impact x urgency system is to enable you to balance those, so you can determine priority and thus greater differentiation of calls to determine working order.

High business impact and high urgency is very important.
High business impact but low urgency is quite important.
High urgency but low business impact is quite important.
Low business impact and low urgency is not very important.

Basically, it's only by considering all aspects of the Incident that you can arrive at a relative Priority that helps you determine SLA and working order.

However, I notice you have 5 staff, and therefore I guess your call volume would be relatively small too. It is a possibility that using both I and U in a very formal sense could be overly bureaucratic for you.

You might want to consider just using a straight Priority, with clear examples. Experience tells me that the more fields an analyst has to complete, the more likely they are to pay lip-service to it, which results in everything having the same Priority!

Better to have one field thought about properly, than two fields completely cursorily, backed by 2 sets of definitions and a matrix that always needs review and thus altered system config!