When a customer asks for something unsupported, and they promise not to get upset when it stops working, don’t believe them

A customer wanted to know how to do something extreme. Let's say for the sake of example that they wanted to disable clicking on things in Explorer. They understood that it might very well not be supported, but "they are fine with an unsupported way."

I asked why they wanted to disable clicking on things in Explorer, especially since clicking on things is one of the most common things people do with Explorer.

The customer liaison explained that the customer didn't want users clicking on one specific icon, so they just want to disable clicking.

I suggested that the customer was trying to kill a fly with a bazooka. If they don't want users clicking on one specific icon, then they can look for a policy to disable that one specific icon.

The customer liaison replied that the customer already did that, but they want to disable clicking on anything, just to make sure. The customer liaison reiterated that the customer would be fine with an unsupported technique, and that the liaison would apply all applicable disclaimers when providing the information.

In practice, these disclaimers have no value. I've seen it happen. A customer does some unsupported thing, and it works for a while. And then it stops working. And then they come back and say, "Hi, you helped us do this unsupported thing, and it worked great for a while, but it recently stopped working. Can you help us get it working again?" In other words, they are asking for support for the unsupported thing.

After all, the fact that we gave them an unsupported thing in the past proves that giving people unsupported things is one of the things we do. Which means that it becomes de facto supported.

Don't fall into this trap. If somebody asks for something unsupported, even if they say, "Yes, we understand that it's not supported," they will treat it as supported. Because their understanding is not "And we promise not to ask for help when it stops working." Their understanding is "We understand that this is something devious that you're giving us, and we appreciate your continuing assistance."

Comments (16)
  1. Vilx- says:

    This reminds me of this one time I wrote an example application for a client of ours. It was supposed to be a demo on how to use our API but it showed them how to do the few things they needed to do. I think I even made the app show a “This is a demo only” popup when it started up. The whole endeavor was billed as a “consultation” with a pretty ridiculous hourly rate but they still happily paid that.

    A year or so later they asked if I could add a modification to the app. Turns out they didn’t want to touch it at all and had just deployed it as-is in production. For over a year the demo app had been used by people in the field to perform actual work.

    It’s lucky I still had the source code lying around in a folder; it wasn’t even in source control. When management heard about this they had a good laugh and then went to talk with them. I don’t know how it ended but I still got to make the modification. This time I checked it in our source control.

    1. kantos says:

      This is why I always make sure that demos don’t actually work, because the sales guys will sell the demo without asking. They assume that a shiny UI means it’s done.

      1. Darran Rowe says:

        Or if you can’t make it so that it doesn’t work for whatever reason, go out of your way to make it a really bad demo.
        I have done things like make it very inefficient, only implemented partial features, only allow the demo to be active for a certain length of time, and make it start randomly crashing after some time.
        The last one is perfect if the timing ends up getting the demo to crash around when they ask about the state of the demo.

    2. cheong00 says:

      This reminds me about something similar… a POC feature is made for demo for bid a contract, I explained to my boss that this feature is not compatible with our database schema and we’ll need over 3 man-month effort to rework the tables in order to make it work without breaking existing program logic, all data saved by the feature is stored in a set of table that is isolated to other systems instead.

      In the end we didn’t won that bid. Instead, another customer saw the demo and want it, and the sales quoted only 3 mandays. Afterall, all things *seems* to work, how difficult would it be to make it actually work, right?

      I refused to do it because I’ve submitted resignation at that time point, because clearly you won’t handover half-baked feature to *non-existant* *next* developer.

      I have no idea how did the matter ends.

    3. I’ve seen the exact thing happen to me. We had an API and had to provide a sample on how to use it. We ended up with a ton of bug reports from a customer that the sample code provided didn’t do their exact integration and use case. It was just a few example API calls; our sample code didn’t do anything useful. But it was deployed as-is, the customer noticed it didn’t do anything and said we had bugs. It is amazing how quick crucial information like that gets lost or glossed over.

  2. lesession says:

    To summarise: no good deed goes unpunished

  3. Rev John says:

    Way back when I did Word for Windows support, probably version 6, someone called in to complain that a feature stopped working.

    Said feature was technically impossible. I couldn’t explain to him how it ever even worked in the first place and that I wouldn’t be able to break the software in such a way that it would do what they liked again.

    They did not take it well.

    1. We’ve had quite a few customers calling for technical support complaining about a feature that stopped working when we know that feature never existed.

      I recall more than one case where we could prove the feature never existed by information theory: the software didn’t have enough information to implement the requested data processing.

      I can’t imaging what’s going through the customer’s heads when they try this stunt. When we don’t know immediately the feature never existed, we can waste days tracking it down before closing the case when “does not exist”. This never turns into an add feature even if it’s a really good idea, which usually it isn’t.

      1. Never attribute to malice that which can be adequately explained by incompetence. They don’t know their actual inputs, they don’t know their actual outputs, they don’t know their actual processes. So they can’t correctly conclude that “existing feature X does (or at least used to do ) such and such/”

        Or at least the person tasked to take the “broken feature” case to the vendor doesn’t know those things. How Suzy in Accounting or Bob in Sales actually uses the tool is anyone’s guess. I’m reminded (for the second time this week) of https://xkcd.com/763/

        1. cheong00 says:

          We had seen something like this in one of my previous company:

          1) Some high rank user don’t want to enter some financial figure in the system, and told us we should deduce the figure from other data.
          2) However, that required figure is used for verifying the correctness of other systems.

          Have told them about this and they say “just do it”, and now we have a system that “always works” but don’t actually work in any sense.

    2. mpswaim says:

      We once had a customer complain that a button that they didn’t need didn’t exist. (We speculated that mid-call they realized that the information they wanted was elsewhere in the app, and that they were saving face.)

  4. So long as the customer pays for each such incident, does it really matter? Or are we talking some sort of fixed-price support contract here?

    1. The deal is that the customer paid for the incident, and the response from the feature team is “Sorry, we don’t support that technique any more.” The customer is now mad. “Well you are the ones who gave me that technique in the first place, and my product / deployment relies on it! You must keep it working!”

  5. peted66616 says:

    It seems to me that your analysis can be rephrased more simply: providing an answer to the *initial* request is also “support”.

    The fact that the customer lies when they say they won’t ask for help if it stops working is immaterial. The real reason to not provide answers to such questions is that you can’t truthfully say that a technique is “unsupported”, while at the same time actually *supporting* the technique by describing it to the customer.

  6. There may be some confirmation bias here, since the customers who don’t understand are the ones you’ll hear from again.

    We use one of our SaaS systems in a somewhat non-standard way; we do all the normal processes, but to get all the information we need out of it we need to use a bunch of internal tables in our final reports. Every time there’s a patch or new release I have to verify that these queries are still valid – and there have been times that I’ve had to update them, as the application changed the way it handled various cases internally. But we always knew we were signing up for that; it’s just part of the cost of doing business.

  7. Alex Cohn says:

    In Android, using the system libraries, e.g. libssl.so used to be ‘unsupported’ for long time. Since recently, it is strictly forbidden.

Comments are closed.

Skip to main content