The Situation
Your help desk logs a ticket in response to a call reporting a problem with an asset the customer believes is under contract. The help desk is trained to respond and ensure the customer’s needs are met and no SLA’s are breached. The problem is that the finance department has recently sent out renewal notices with a price increase and the customer has decided not to renew support, without telling its operations staff. Would your help desk know this change had taken place or would they simply provide support anyway? Would they even be able to find the asset tag in the help desk system?
Unless this data is centrally maintained and delivered accurately to the help desk ticketing system you cannot be certain that you are not (on occasion) providing service for free.
Federated Data
This is not just about telling operations that a support contract has been cancelled. It is about complete data alignment from a sales order, through the asset on-boarding process, mapping to support contracts and SLA’s and the right project to book the ticket to (reflecting the money spent by the customer for support of that exact asset).
This data touched by this scenario is likely to exist in the many systems:
- A contract database (often a spreadsheet), owned by the finance department
- A ticketing system, which should also models the assets, though these are frequently in a separate database, both owned by the operations department
- A timesheet system, probably owned by finance again
- And if you need to raise a quote to do the work, you’ll need access to the quoting system, owned by sales.
Even getting the right customer record can be a challenge, let alone whether the specific asset reference they are reporting an issue with has been mapped to a contract and is under support. It’s not too hard if everyone is in the same office, but if you as spread across many offices and have centralised your help desk, staff have to rely on what they can see online.
The problem is made tougher still because the data does not stay static. Customer needs change continually, assets get replaced, taken off support, added to etc. Even answering the simple “what is an asset” question can be a challenge.
Maintaining Data in Sync
The answer is a data architecture that keeps the score across all these disparate processes.
This data architecture needs to ensure that when a customer calls and takes an asset off contract, the finance department can both amend the scope of the support contract, but also know how much to change the billing. Both of these have to become effective on the day after the cancellation date. So, finance would need to mark the asset as not being covered from a particular date in the future. Most asset registers don’t support this functionality, assets are either under support or not.
The contract database may be able to model the date at which the coverage of the support contract will change, but it will have no view of the exact assets. So, to be accurate, finance will have to amend the asset register on the day the service ends. In the real world, this rarely happens.
Also, as the contract was amended and presumably, the price reduced going forward, the budget for the support project in the timesheet system should also be amended downwards to ensure these two views remain synchronised. Finance should have the access rights to do this, but will they remember?
Finally, assuming all this has happened correctly, the customer still has a broken asset and presumably wants it fixing. This is a revenue opportunity. Can your support desk access this revenue opportunity by raising a quote, in the context of the ticket (for traceability), and forward it to the customer for their approval to proceed? If they have to call sales and get them to raise the quote, it probably won’t happen, or it will be too slow. So, we may be back to just helping the customer out this time and never mind the fact that they are getting work done for free.
Keeping control of this simple data model is harder that it first appears. It is actually quite a complex and date-based data process that is poorly served by fragmented databases and multiple stakeholders. This is before you consider the overarching MIS needs to help management understand how effective their support organisation is at meeting budgets. Buy multiple systems to support this process and the data architecture becomes your problem.
HarmonyPSA
Harmony is designed to solve this entire problem in a single integrated solution with a single database. The help desk can see exactly the state of the contracts and which assets are under support at any time. You can also raise a quote directly from the ticket, capturing that hard to manage revenue opportunity. For more information on how Harmony can help you control your enterprise data contact us for a demo.
