Opacity of the conversation offer system
Within Dixa the system is designed so that all conversations that are placed into a queue are offered to agents assigned to those queues, and the options for configuration within this system are reasonably vast. Between queue priority, agent priority within a queue, and the means by which conversations should be offered it can be very difficult to explain after the fact why conversations were offered in a specific manner.
If something bears out in the conversation offer/acceptance/transfer data in your Dixa instance, it may not be clear which mechanisms are responsible for how conversations were offered, nor what means you should take to remedy the situation. Take, for instance, the "Longest idle, according to agent priority" offer algorithm option--it sounds straightforward, but that option applies to each queue individually, but is not specified whether idle time is specific to that queue.
Fortunately this really only becomes friction in more complex Dixa setups, but if you encounter it you may find it to be very difficult to unravel. The recommendation here is to keep things as simple and streamlined as you can.
Lack of reporting/analytics customization
While Dixa has a good variety of data available regarding the activity in your Dixa instance, the reporting functionality is pretty limited. For each of the analytics verticals you can select portions of channels, tags, contacts, etc. to include in the reporting available but you're restricted to the reporting that is available within their platform. For instance, the "Productivity" vertical shows you handle time, wait time, and volume of conversations answered and can be split by queue, channel and/or contact point. You cannot, however, see how handle time for specific tags differs within Dixa. For something like that you would need to export your data into another platform or tool.
Similarly, another within the "Agents" vertical of Dixa's analytics you can see conversation assignments by volume and percentage across your team, but you can't include average handle time or other metrics into this view in Dixa--the inflection points for this view are agent, queue, channel, direction, and contact point. Referencing a different type of data (tagging, CSAT, productivity, presence) into agent productivity data cannot happen within Dixa's analytics functionality.
Fortunately Dixa's exporting functionality works smoothly and provides extensive data to work with in a program like Excel or Numbers, but it can sometimes be challenging that the in-app reporting functionality isn't more configurable.
The most glaring lack of functionality within Dixa can be found with its integration with Salesforce. While Dixa does include a native integration, all that integration is capable of is displaying information related to leads in your Salesforce instance in the conversation sidebar. Moreover, the information provided out of the box is very limited.
You can customize the sidebar app to have your own styles and include significantly more information within the sidebar card, though the information available in the sidebar depends entirely on the structure of your Salesforce account.
This integration is a one-way integration that only displays information about Salesforce Leads in Dixa, and does not send any information to Salesforce or display information about Dixa conversations within Salesforce. To accomplish each of those things you would be required to build your own middleware (which is definitely possible) or use a platform like Zapier to automate this (again, possible, but with limited functionality).
Dixa is still a relatively young software, and as a result there are some portions of their functionality that haven't reached full maturity. More functionality and refinements are released regularly, and for the functionality that's unavailable within the application, Dixa have provided good resources in the form of data exports and robust APIs for you to meet those needs outside of their application. The good news is that many of the areas in which their product doesn't deliver are on the more advanced end of things and are less likely to matter for organizations that are looking for a relatively simple solution.