Company - Client Transparency, is it a good thing?
One of the reasons I started this blog was to open discussions around the ‘best practices’ of Client Services I’m implementing at Serious Fox. One thing that I’ve always believed in, maybe to a fault, is client/company transparency - complete openness about the good and the bad things that come along in a project. As far as I can see it, there are three main areas of transparency: Price, Timings and Development Progress. Being open with a client around these three areas builds trust, and as most people know trust is the key to happy working relationships and creating workplace based in collaboration.
Obviously there is a lot of risk with complete transparency with clients. A lot of agencies I’ve worked in run from this kind of open/frank communication because with complete honesty comes the risk of having to admit that your company did something wrong, charged too much, or perhaps even worse - promised something that couldn't be fulfilled. However, in my eyes with this risk comes some pretty significant benefits. There is something to be said about gaining a clients trust, knowing that you can be honest with them about the good and the bad. By being honest about a project that will take little time and money (versus trying to milk the client for more money) means that when that timely, expensive project shows up - the dreaded time/price negotiation is minimal because the client trusts you are being honest.
This sort of transparency does put an Account Manager into some pretty difficult positions. Just the other day, I had to throw my hands up and admit a company mistake. We under-estimated the time it would take to fix a bug, and in turn we were going to go over on budget and miss the deadlines. While in the past I was coached not to admit blame, or try and dodge the subject, I took it upon myself to expose the real cause of the problem, which was our estimate. If you work in the development world, you know these things happen almost too often. Estimates are based on little investigation, and it isn’t until you really get into the code that you will realise how much time it will actually take to fix a bug - or create that new feature. It’s also one of the hardest situations to explain to a non-technical client. Normally in these situations, you either damage client relations by demanding more money for resource - which is above what you quoted and approved. Or, you end up fixing it for free - which means you have lost revenue and potentially set-up the expectation that these things will be fixed for free going forward. What was the outcome of this conversation? While the client was disappointed, we both agreed that estimates needed more investigation time - and a better, more efficient work flow was established for the two companies.
Now I do realise that this is a bit of a ‘in a perfect world’ theory. Just as developers and account managers have been burned by clients - clients have been burned by companies. It will take quite a lot of work to earn the trust of some clients, and some trust may never be earned. But at the end of the day, I can always walk away from a situation knowing that I did my best and told the truth - and whether or not the client wanted to believe me, that was the situation. In my experience, this has worked more times than not, and I have several life-long friends who used to be clients (or even still are). My hope is that through implementing this way of working with Serious Fox, we stop arguing over timings and prices, and can walk away at the end of the project with both parties feeling that they got a fair deal.
Over the next few weeks I'll be taking a look at the pros and cons of transparency in the areas of Timings, Pricing and the Development Process.