Use the following questions to determine whether support should perform data repair.
- Was the data error caused by a defect in the product? If so, perform the data repair. If not, proceed to question 2.
- Assuming the data error was caused by the user, can it be fixed through the front end in a reasonable timeframe? If so, do not perform data repair. The customer needs to make the correction through the front end. If not, proceed to question 3.
- Assuming the data error was caused by the user and cannot be fixed through the front end in a reasonable timeframe, would it take 10-15 minutes or less to fix through the backend? If yes, then perform the data repair. If not, send the case to sales to quote for professional services to fix through the backend.
Important Note – Use good judgment when evaluating how long a data fix will take to implement. A query almost always takes more than 15 minutes even if it seems simple, since the customers usually ask for additional tweaks after receiving the first query draft. Oftentimes you will want to ensure a data fix is ran against a sandbox[which may need to be refreshed] before applying it in Production. If you aren’t sure, email the customer exactly what you plan to do for the data work, and get their approval confirming that if they end up needing more they will need to have their request sent to sales for a project quote.
Why We Do This
- Data errors that were caused by the software are our responsibility to correct, regardless of how large or small the error is. You can recommend a front-end fix to the user, and sometimes they are okay with this. But if they decline and insist on a backend fix, we should assist them where reasonable.
- If the customer caused the data error, then the fix is not covered by their support fees. If they want us to correct it through the backend, they would need professional services to quote this as a special project.
Exceptions
If the data work would take less than 15 minutes to perform, it is not worth the time of the sales rep and professional services rep to quote for this. This happens when
A. There is a front-end fix. – in this case they should do a front-end fix
B. The data repair itself would take less than 15 minutes. – in this case, support should perform the backend fix
Unsustainable Situations
It may seem like assisting customers with quick data work creates a positive customer experience, but if the data work does not meet these outlined criteria it is unsustainable and creates a frustrating experience in the long run.
Helping the customers today makes them happy today, but when they contact us in the future and we don’t have the bandwidth to perform the same data work, this creates an inconsistent experience and frustration with our policies from setting unsustainable expectations.
Let’s say while on a call, the customer asks us to make a quick data change for an error they caused themselves that could be fixed through the front end. One request of this nature may not seem like much, but once they believe we will make these changes, they will ask for it again and others in the future. A handful of customers who all reach out periodically for small data fixes adds up, and takes up a significant amount of support resources, resulting in hours of free data work that was not covered by their support fees, and making your peers unavailable due to the frequency of requests.
NOTE: You are able to convey any customer urgency and escalations to Sales when forwarding the case so that time-sensitive issues are quoted and routed as quickly as possible by Sales and Professional Services. This ensures the scope of work and a dedicated resource works with the customer until they are satisfied with the results.
Example Scenarios
- A customer reaches out and asks us to move a job invoice from one customer to another. Upon investigation, we find the job bill to was pointed to the correct customer, but a defect in the sub/master billing caused the invoice to end up on the wrong customer. - In this scenario support would perform the data repair.
- A customer reaches out and asks us to move a job invoice from one customer to another. Upon investigation, we find the user created the job on the wrong customer.- In this scenario, since the user created data error themselves and there is a front-end fix available, we would explain to the customer how to credit off the invoice and create a new misc invoice on the correct customer.
- A customer reaches out and asks us to change the date on their last batch of cycle invoices. You determine through research or customer admissions the customer caused this data entry error by entering the wrong invoice date on their cycle batch, but fixing every invoice (there could be hundreds, or over a thousand) by hand is not feasible. The data repair would take less than 15 minutes. – In this scenario, support would perform the data repair.
- A customer reaches out and asks us to back out a rate change they performed. They caused the issue by entering the rate change incorrectly, but manually fixing every affected recurring line is not feasible, and correcting the data would take more than 15 minutes. – In this scenario the case would be sent to sales to quote for a project.
- A customer requests a quick query to show them all of their customers who had more than 5 jobs opened for them in the last 6 months. This query is beyond the capabilities of the query builder. – In this scenario we should use good judgement. The standing recommendation is to send the case to sales for quoting. Or if you are confident, you could provide them the query as long as you first make it clear that if they want any changes to the query you provide, that request would have to go to sales for a Project Quote.
