One of the most challenging things about running an agency is determining when and how to tell a client “no”. Most agencies are apprehensive to decline a client’s request because of the desire to always make the client happy. And some businesses react strongly when they don’t get what they want from a vendor. But in many situations, “no” is the best answer for both the client and the agency.
Often times, when you have a long and trusted relationship with a client, they’ll turn to you for any/all of their loosely-tech-related questions or issues. We routinely find ourselves providing generic desktop support, attempting to decipher local network or DNS issues, helping with other software tools like Sharepoint or Salesforce, etc, or just advising our client on business-related decisions that don’t necessarily relate to their web experience. None of these are areas of service that E-dreamz provides, but we always try to be helpful where we can in the interest of providing solutions for our clients. The challenge with that, though, is knowing when you’re extending your agency into a support role that you’re not suited for.
E-dreamz provides fully-managed web development, digital marketing, and support service. We have our own proprietary, custom-built Echo by E-dreamz platform that we provide as a software-as-a-service model. Through this model, we host, develop and market all of the sites we operate for all of our clients. This ensures that we’re in full control of all technical aspects of our websites and that we can provide the best possible quality of support for those sites. We know what we provide and what we’re good at. And we know when what a business is asking for isn’t a good fit for our agency.
A few years ago, one of our long-term clients asked us to build them an Echo-based website but insisted on hosting it themselves. A key part of our service model is that we host all of our websites so that we have full control to deploy updates, apply patches, and upgrade our Echo base as needed. In this instance, we should have told the client “no”. But because of the long, healthy relationship we had with the client, we made an exception. That was a mistake.
Even though we stated clearly that we would not and could not provide system administration support for external hosting environments, the client chose not to engage with any other group for that service and expected E-dreamz to fill that role. Though we tried to say no, we failed to do so confidently and assertively, and we ultimately relented to the pressure of the business.
Since then, we have become the de facto support contact for this business’s IT, group, whenever they have issues with their third-party hosting environment. E-dreamz has little to no experience with this host and does not provide third party server management or consultation as a service. That extends well outside of our normal service offerings. And yet, we are now stuck in a situation where our CTO has to personally support an anomalous website that differs structurally from every other product we maintain. This, of course, is bad for both us and the client. We’re providing the support that we’re not properly staffed or experienced to provide, and the client is relying on a vendor for the support that the vendor can’t competently provide. The result, naturally, is friction and a poor quality of service that ultimately damages the good relationship between the two parties.
In this scenario, we should have said “no” and encouraged the client to select a new vendor more suited to their needs.
Firmly, directly, and with an understandable explanation of why the request can’t or shouldn’t be fulfilled.
I think much of the apprehension in saying “no” comes from the fear that the situation will become contentious if the agency declines the client’s request. Some businesses don’t like to be told “no” by their vendors. Often times, the immediate reaction is to pull in higher-ranking leadership from both sides who may not fully understand the nuance or ramifications of the request. When that’s the case, it’s critical that representatives of the agency explain why they cannot fulfill the request in understandable, detailed terms so that leadership sees the invalidity in what they’re asking of the vendor. If done effectively, an amicable resolution is usually reached. Smart business leaders don’t want to rely on vendor partnerships that can’t fully meet their needs. Even if it means the client-vendor relationship changes or ends, the business will appreciate the honest way the agency affirmed their position.
Sometimes, though, the business won’t accept the explanation and refuses to accept “no” for an answer. This, in my opinion, is the most difficult situation for an agency to navigate. In my example above of providing third-party hosting support, the client wouldn’t take “no” for an answer, brought in their C-level leadership, leveraged their perceived weight against our own, and ultimately coerced us into giving them what they wanted.
The end result was our CTO helping the business’s IT team hack our Echo-based website to operate on a version of PHP it was not designed for, which means the website can now never be upgraded properly and is out of sync with the source code, preventing automated deployments. It is a poor solution, a bad situation for both parties, and the product suffers because of poor decision making.
By listening, asking questions, and looking for an alternative solution.
If you’re on the business end of the relationship, and your agency declines your request, you should respond to that with whatever questions you have to help you fully understand why the agency can’t or won’t fulfill your request. Agencies don’t typically say no to their clients - the for-hire nature of the relationship is the agency’s very lifeblood. So when an agency says no, there’s usually a good reason. Often, that reason is technical. If you don’t fully understand the agency’s technical explanation of why they can’t provide what you’re asking for, simply continue to ask questions until you do. Once you see the reason behind the declination, you’ll likely appreciate the information your vendor was able to provide.
What you shouldn’t do is attempt to bully or coerce the vendor into doing it anyway. You’ll put both your business and your vendor in a bad situation if they relent. This is what happened in my example with the now misconfigured, un-upgradable site. That business would have been far better served if they’d listened to us when we attempted to explain why they would be better supported by a vendor that offered that type of support. I used the lousy analogy of having your plumber fix your air conditioner. If you throw enough money at him, he’ll probably take a look at it. But it’s not an efficient use of his time or your money. You’d be far better off taking the time to find and hire an HVAC repairman for your air conditioner and rely on your plumber only for the services he provides.
Go back, re-communicate, and prepare yourself for a tougher conversation.
As we noted above, knowing when to say “no” and knowing how to effectively say “no” are two different things. It will often seem easier at the time to simply decide, “Well, we’ll do it for the client just this once.” The problem is, in the world of vendor-support, there’s no such thing as “just this once”. If you’re not prepared to provide ongoing support for the service you’re agreeing to, you need to say no. But if you’ve made the mistake of saying yes, and now find your agency in an untenable situation because of it, your task of saying no has now become more difficult. An expectation is already in place with the client, so they’re going to be even more unhappy hearing your refusal to continue to provide the support they expect of you.
That doesn’t mean you should allow the situation to persist, though. In our example here, we’ve been providing third-party hosting support for one client for four years. E-dreamz hosts manages, develops and supports, more than one hundred websites on our servers through our standard process. And we support exactly one website on a poorly-configured third party shared hosting account. The hindsight is plain and obvious: we should have said “no” initially, and we certainly shouldn’t have let the client bully us into saying “yes” for so long. We are very much at fault for the poor experience this client is suffering in their web application for not more effectively explaining why we couldn’t fulfill their request.
This is all just one example of where we failed to say “no”. There have been many instances where declining a request was met with the kind of understanding and appreciation from the business that we would expect. But we like to highlight this one negative experience to reinforce the importance of fighting through the conversation until an understanding is reached. It’s not always easy, but sometimes “no” is very much the right and only answer.
© 2020. All rights reserved. E-dreamz, Inc.