|Summary:||This article explains how you may use either Microsoft Dynamics 365 or aBILLity as your system of record when handling tickets/cases.|
|Related Product(s):||This article relates to the following products:|
|Related Articles:||aBILLity Standard Solution User Guide|
The aBILLity platform and the Microsoft Dynamics 365 platform both perform very separate functions. Dynamics 365 is primarily a Sales CRM system, and aBILLity is a billing platform. However, there is a slight overlap in functionality when it comes to Service Management. Both aBILLity and Dynamics 365 have a service management component in “Service Desk” and “Cases” respectively. Data is passed between the systems in both directions but in a practical scenario it is unlikely that the Service Management function would be operated from both systems. So which platform should you use when managing tickets/cases? Ultimately, you could use either – depending on your requirements and business processes.
Dynamics Dynamics 365 has arguably the more comprehensive functionality when it comes to Service Management. However, if you are already using aBILLity Service Desk and this has all the functionality you need, then there may be no advantage of using Dynanmics 365 as the system of record.
Ultimately, if you require more comprehensive functionality then you should choose Dynamics 365 to be the system of record for Service Management.
There may be some benefit in having the case details in aBILLity however – perhaps only for informational purposes for billing staff, but especially if you use the WLR3 module for reporting Openreach cases.
An example scenario of this would be:
- A client calls and a fault is logged in Dynamics 365, an amount of investigation is performed.
- If diagnosed as a line fault, this case can be pushed to aBILLity where it can then be progressed with Openreach.
- The service staff would use aBILLity Service Desk to log the fault with Openreach.
- Updates and notifications will come back from Openreach into the aBILLity Service Desk incident, which will subsequently synchronise back to the Dynamics 365 Case. This way the Service staff can still manage the case predominantly in Dynamics.
If you have chosen aBILLity as the system of record this will likely be because the functionality in aBILLity is sufficient and/or you probably already use it for this purpose. In this scenario there is great benefit to synchronising case and service level information back to Dynamics 365, but this will only be for informational purposes. As previously mentioned, although data transacts both ways, it’s unlikely that users will really be operating in both systems. But to have this case information back in Dynamics 365 for read only purposes will be useful for Sales staff.