Now what’s a good service and what’s a right service? The good service code goes like this – being ready with a solution before a customer asks for it, analyse the issue to confirm if it involves your solution (concentrate on delivering your solution), do whatever the customer asks for, faster turnaround time for issues (even if it involves a ‘quick and muddy’ solution). But at Ashnik, we do the exact opposite – We deliver a ‘right’ service!
Here’s how – in our case it starts right with pre-sales, where we walk-in blank and hear-out customer’s pain points and then position our technology accordingly. To put it simply we don’t have a pitch for pre-sales, because we have a ‘new pitch’ every time we meet a new customer or work with the same customer on a new project.
While designing the solution architecture or delivering it, we don’t go by a customer’s request to use a popular feature. We’d rather deliver what the exact need is and not what they ask for. By understanding the end user’s requirements, we at times propose a solution which may not be what the customer requested. This does take more time, but it ensures that the customer is getting a correct solution.
During the implementation phase many of our consultants come across bad application design e.g. poor transaction management leading to bad performance. In those scenarios instead of saying ‘it’s not a database problem’, we work with application team to fix it. In this case, a good way to overcome application design is to implement pg bouncer (a lightweight connection pooling agent for PostgreSQL). Though the application bug remains but we take care of it at database level helping customer go-live on schedule.
Post-delivery, the services team continues to showcase the ethics of good services. We educate the customer about the problem, cause and resolution. For instance, if a customer complains about high memory usage, instead of pressing the ‘panic button’ and reducing the database ‘shared_buffer’ – we would take a detailed look at OS memory utilization and usage pattern. Though this is not a DBA’s duty, we would conduct these examinations to determine the exact memory utilization. At the end of such an exercise, we can share a detailed report with the customer, educating them about the various parameters and metrics related to memory utilization and usage.
To put it simply – Understand, Help, Resolve and Educate! These ethics have always got us accolades and bagged us long term relationships with our customers.