Without really knowing any of the information that you have on hand, I can suggest some basic strategies that you can consider for feature prioritization, which you can combine to create a weighted feature list that should suit your purpose. For each of the categories listed there are a number of different ways in which you can score the features (old or new) based on how important or difficult you think they are (e.g. a 1-3 scale to keep it simple), and then tally them up to get a final list (you can also give heavier weightings to categories that are more important).
- Business objectives/requirements (needs versus wants important to consider)
- User objectives/requirements (needs versus wants important to consider)
- Technical feasibility/constraint
- Design/development team skills
- Design/development effort (time and complexity/size of task)
- Frequency of usage by users (how often is this a pain point for users)
- Volume of usage by users (how many users does this pain point affect)
So your competitive analysis on similar applications will give you some idea (in consultation with a business analyst or business stakeholders perhaps) on how to prioritize based on business objectives/requirements. You can then use the call-in data to prioritize based on user objectives/requirements, but you are making the assumption that this information reflects the overall user group (which I suggest you validate through some analytics perhaps, since users might have issues with the feature but not call in to complain or ask for help).
What will help you assess the impact on the users as part of the user objectives/requirements analysis is to look at the frequency and volume of usage, and you can even assign a 'severity' category that is either a combination of the frequency/volume measures, or base it on how badly the users feel that not addressing this issue is for them (which is a more qualitative measure).
Depending on your software development process/cycle, you then need to prioritize based on what you think is technically feasible, so then there is some prioritization in consultation with the technical lead, and they may assess this list based on the overall team skills, effort and the time/budget provided.
I think that will keep you rather busy and provide a good starting point to home in onto what the design/development team should tackle first (with the blessings from business stakeholders). But I am interested to hear if other people come up with different suggestions.