The Good And Bad Kinds Of Price Sensitivity

Previously, I’ve written that price-sensitive customers are bad customers. But what I failed to mention is the obvious: Everyone is price-sensitive.

In fact, price sensitivity is a good thing, on the whole. A client who isn’t looking for the best deal he can get is a fool. You don’t need me to tell you how annoying working for a fool can prove.

So what do I really mean when I speak negatively about price sensitivity?

I don’t mean that anyone who complains about a price is a bad customer. I mean that any company which refuses to pay a reasonable price, questions the fundamental basis of a bid, wants to revisit price after an agreement has been made or never stops trying to get you to lower your price, is a bad customer.

Because yes, as you go through life as a freelancer, you’re going to hear a lot of “no” that is, at the end of the day, really, “I don’t have that kind of budget.” And that’s OK.

It’s the customer that is always cash-poor (or, at least, always claiming poverty) that you need to avoid, and I’d like to talk about how you identify those companies.

Photo by stevepb via Pixabay, in the public domain.
Photo by stevepb via Pixabay, in the public domain.

How A Customer Sets A Budget

Most businesses seeking contract labor have a budget for a given project. For example, when a customer decides he needs a website, he comes up with a budget.

That budget is generally informed by things like:

  • If this is a revamp, how much did the original website cost?
  • How much did others seeking similar results pay for the work? (e.g., How much did Bill, his golf buddy who had his website redone last year, pay?)
  • How much of this work can be farmed out to staff / obtained on the cheap from third-party vendors?
  • What does his pricing research indicate is the “going rate” for the work he wants done? (e.g., when he Googles “web site coding,” what prices are spat back at him, and what sense can he make of that pricing?)
  • Can he squeeze the organizational budget for additional dollars or does this have to be done with money on hand?
  • Is this a priority for the organization?
  • Does it need to get done quickly?

Needless to say, this can cause all kinds of trouble with your client’s request. Many has been the time that I have entered into a negotiation with a client and spent a significant amount of effort clarifying what was actually needed (versus what the specification requested), whether current staffing and workflows would support what the customer wanted done, and whether that could be provided for a budget that appeared to be within the customer’s ability to pay.

That is to say, a client may well come to you with a request for a WordPress site, because he knows it’s generally easy to operate, flexible in terms of presentation and that WordPress development labor is cheap, on average.

All that is true as far as it goes, but it may be that he has some needs that aren’t easily accomplished in WordPress (for example, very granular user permissions, or very specific content aimed at particular groups of users). In those cases, you need to be prepared to snoop out the difficulty and adjust your bid accordingly … and do it in a way so that the customer understands why your bid isn’t what he was expecting.

Photo by RyanMcGuire via Pixabay, in the public domain.
Featured photo by RyanMcGuire via Pixabay, in the public domain.

Haggling versus Arguing

This brings me to the point: There’s a difference between haggling and arguing.

Most customers are going to want to haggle over price, unless you are bidding far below the budget they had in mind.

You can tell if someone is haggling when they complain about the pricing not at its core, but on the edges.

What I mean by that is, let’s suppose someone wants you to create a WordPress site, and it has some features and some specifics about how it should appear on certain devices. So you bid, and it turns out to be more than the client expected, but close to his budget.

  • If the client asks whether changing the responsive template needs would reduce the cost, he’s haggling.
  • If he asks you whether you can reduce your price by 10 percent, without changing the specification, he’s haggling.
  • If he asks you to do the project in stages, in order to draw out the length of the project so he can get into another budget cycle for final payment, he’s haggling.
Any time someone agrees to your price without haggling, it’s generally because you underbid the work; he was expecting a much larger price tag.

There are two exceptions to that case.

Sometimes, the price of something is so obvious that there’s no point in haggling. For example, if a customer knows your open rate is $70 per hour, and it’s obvious what he’s asking you to do is going to take you about an hour to do, nobody is going to haggle over a bid of $70.

Some customers are pound-foolish. In other words, there are customers out there that will quibble over $10 for days, but will write you a check for $10,000 without batting an eye. These customers are rare, not the least reason for which being that they tend to spend themselves out of business.

A client is arguing when he wants to change the core of the project, or he scoffs at your bid in any way.

For example, if a client wants you to make a site that includes a fully integrated WooCommerce site, but decides to use SquareSpace after seeing your bid, that’s a bad client. At best, he doesn’t have a plan. At worst, he has neither the will nor the wherewithal to succeed.

Likewise, if you bid $5,000 for a project and a client says a competitor’s bid was $3,500, that’s arguing.

Trust me, you cannot reduce a bid by 30 percent and maintain a respectful relationship with a client. Either the client is going to look at every future bid as an attempt to gouge him, or you’re going to wind up working much harder than you should for less pay than you deserve. Either way, the relationship is over before it started.

Alternatively, if the client questions the validity of your bid in any way — that is, he effectively suggests your work is not worth what you bid — you should abandon both the bid and the customer.

This also applies to suggestions that you did not understand a request for proposal; that the project is not as complex as your bid implies; that there are alternatives to your proposed solution that are cheaper; etc. These are all expressions of mistrust, and a business relationship that starts out with mistrust is never going to generate trust.

A customer who does not trust you, or a customer you cannot trust, is a bad business relationship that’s only asking for trouble.

The Chain Bridge in Budapest, by blizniak via Pixabay, in the public domain.
The Chain Bridge in Budapest, by blizniak via Pixabay, in the public domain.

The Middle Ground

Which brings us to the gray area between haggling and arguing. When, specifically, is the line crossed?

In my mind, haggling should be front-loaded: When you first take on a customer, some haggling should be expected. But it should ease as your relationship grows.

The first couple of projects should give you an understanding of what the customer can afford and how realistic his expectations prove; in the same vein, he should come to understand how valuable your labor proves and how consistent your service is.

In that kind of business relationship, you work toward trust, and as it’s established, the quibbling disappears and the outcomes become predictable.

If you dicker over every initial bid, three years into the business relationship, you’re arguing.

If the customer wants to revisit pricing after agreeing to a bid, you’re arguing.

If the customer complains that something is expensive, but still signs the check, you’re haggling.

If the customer tells you he has to go with someone else’s bid, you’re arguing … but that may not be a good enough a reason to cut the customer loose.

Sometimes, customers have projects they know are under-budgeted dogs, but they have to get them done for that price, so they hire someone they don’t respect to plow through it. The client may well continue to hire that other contractor for work — and it’s possible they prove a better value than you are — but as a rule, cheap contractors aren’t long-lived.

Photo by DariuszSankowski via Pixabay, in the public domain.
Photo by DariuszSankowski via Pixabay, in the public domain.

Time And Experience Tell All

Ultimately, it comes down to experience.

As you learn how to vet a request for proposal, and discover what the client really wants versus what he asked you to do, you’ll learn how to spot non-starters and clients whose budget is widely out of touch with the project’s needs.

As you work with more clients, you’ll learn how to spot someone who is penurious versus someone who is frugal.

Protip: Misers don’t respond to logic. If you explain the benefit of spending more, but the client doesn’t hesitate to reject the idea, that’s because he cannot, or will not, spend more.

Ultimately, if you are any kind of successful at self-employment, you’ll also learn that the right attitude makes a big difference in price resistance.

  • When you take the time to understand the customer’s need;
  • when you have a positive attitude about solving the problem;
  • when you invest the customer in your solution; and
  • when you delay talking about price until that investment has been made

you will find that any price resistance is token, and that any bid that is not wildly outside the customer’s ability to pay will gladly be accepted.

As I have said before, I will say again: There is no limit to the money most people will pay to have problems go away and to feel good about a situation.

Within reason, of course. Experience will show you where “reason” lies.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

  • Check out the Commenting Guidelines before commenting, please!
  • Want to share code? Please put it into a GitHub Gist, CodePen or pastebin and link to that in your comment.
  • Just have a line or two of markup? Wrap them in an appropriate SyntaxHighlighter Evolved shortcode for your programming language, please!