A good service code goes like this - being ready with a solution even before a customer asks for it, analyse the issue to
confirm if it involves your products (concentrate on delivering your solution), do what the customer asks for and provide
faster turnaround time for issues (even if it involves a 'quick and muddy' solution).
But at Ashnik, we do it a little differently - We deliver a 'right' service!
Here's how - in our case it starts right with pre-sales, where we walk-in with open mind and hear-out customer's pain points, identify right solution and position our technology only if it makes sense. To put it simply we don't go with a 'one solution fit all' kind of pitch during pre-sales, because we have a 'new pitch' to fit customer solution, 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, our focus is not to please the customer just by incorporating most popular feature because it is 'in thing' to do. We'd rather deliver what the exact need is and not what the product has. By understanding the end user's requirements properly, we at times end up proposing a solution which may not have been considered by customer's internal IT in the initial phase of discussion. This does take additional time, but it ensures that the customer is getting a 'right' solution.
During the implementation phase many of our consultants come across challenges due to application design e.g. poor transaction management leading to bad performance. In such cases, instead of saying 'it's not a database problem', we work with the application team to fix it. For example, in this case, one of the ways to overcome application design challenge is to implement pgbouncer (a lightweight connection pooling agent for PostgreSQL). Though the application bug remains but we are able to overcome performance issues by providing a solution at database level thereby helping customer go-live on schedule.
Post-delivery, our services team continues to showcase the ethics of right services. We educate customers 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 helped us establish long term relationships with our customers.