[rails-business] How to "fire" a difficult client?

2 views
Skip to first unread message

Brian Hogan

unread,
Jun 18, 2007, 11:24:31 AM6/18/07
to rails-b...@googlegroups.com
I'd love to hear how others have had to let a client go.   What steps did you take to ensure a somewhat amicable split?  When do you know it's time to let a client go?

I've got one right now where my gut is telling me it's time to let him go, but I'm not sure how to do it and would love to get some advice.   Here are just a few of my issues:

 1.  He's always in a hurry, so he doesn't want to spend a lot of time coming up with requirements, and so we find out new requirements after the system is live... then everything is an emergency and other work has to be delayed. (impacts other clients.)

2.  He wants everything fast and cheap. We spend more time than we should convincing him to pay.

3. Everything's our fault, whether it's the hosting provider running into unexpected downtimes, or the time when the merchant account vendor we recommended closed his account because he was using it inappropriately.

4. He doesn't pay on time.

I would love to hear some advice.  He does seem like the kind of guy who would spread bad publicity if this goes down wrong.  How would you deal with this?






Mike Gunderloy

unread,
Jun 18, 2007, 11:40:54 AM6/18/07
to rails-b...@googlegroups.com
I wrote about this a while ago for Web Worker Daily:

http://webworkerdaily.com/2007/03/26/the-why-and-how-of-firing-clients/

Check the comments too for good advice & war stories.

Mike Gunderloy
http://afreshcup.com

Paul Robinson

unread,
Jun 18, 2007, 12:24:56 PM6/18/07
to rails-b...@googlegroups.com
On 18 Jun 2007, at 16:24, Brian Hogan wrote:

> I'd love to hear how others have had to let a client go. What
> steps did you take to ensure a somewhat amicable split?

Generally by being pleasant, and at no point being accusatory. E.g.:

"We're finding it difficult to give you the service you need, because
our business priorities have changed a lot[1] since you came on
board. Here is a list of our local competitors you might want to take
a look at who we think would be a good fit, and we'd be happy to work
with them to make sure you get transferred across easily. We'll stick
with you whilst you make your mind up, but it's going to be in your
best interests to make this move in the next 3 months otherwise we're
going to get into support issues"

[1] - never, ever lie here. Your priorities have changed: your
priority is not to deal with this client any more. Don't go into
details if you don't want to. He's not your Dad, and you haven't just
borrowed the car without asking.

If that doesn't work, hike your prices so he feels insulted and looks
elsewhere. Worst case scenario, he sticks with you but is paying
twice as much money. One of the biggest flags to me is when a new
potential client starts a meeting with "I have a site with these
guys, but they've just pushed their prices up 4x in 12 months so I
need to move..." :-)

> When do you know it's time to let a client go?

When I don't want to speak to them any more.

> 1. He's always in a hurry, so he doesn't want to spend a lot of
> time coming up with requirements, and so we find out new
> requirements after the system is live... then everything is an
> emergency and other work has to be delayed. (impacts other clients.)

Sounds like you're lacking formal Change Request Procedures and
client sign-off, or if you have them you're not enforcing them. This
is partly your fault if you don't have something from your client
saying "Yes, that's OK, launch with this", which you can then go back
to him with. It might be difficult to negotiate SLAs and CRPs with
difficult clients, but at the end of the day it's got to happen to
all businesses sooner or later.

> 2. He wants everything fast and cheap. We spend more time than we
> should convincing him to pay.

Is this guy your only client? If yes, you need to get better
marketing. If no, allow him to walk away. Don't ever argue, don't
ever try and beg him to see reason: "This is the price. I doubt you
can get what you want elsewhere as high a quality for this price, or
with people who understand your business the way we do, but if you
want to shop around, we won't take it personally". If he argues with
you, shrug your shoulders and just say "this is the price". Always
get the price agreed before you do the work.

If he can get what he wants for less money, and of equal quality,
with people who understand his business just as well, well, you're
too expensive for him on that one: c'est la vie.

> 3. Everything's our fault, whether it's the hosting provider
> running into unexpected downtimes, or the time when the merchant
> account vendor we recommended closed his account because he was
> using it inappropriately.

You need to clear up exactly what you do and don't provide. If his
contract is with you and not the hosting provider, the hosting
provider going down *is* your problem. However, it sounds like this
one is down to poor communication.

> 4. He doesn't pay on time.

If he is in breach of invoice or contract T&Cs then shut his site
off. He'll pay soon enough. If he doesn't, you don't need to worry
about how to fire him.

> I would love to hear some advice. He does seem like the kind of
> guy who would spread bad publicity if this goes down wrong. How
> would you deal with this?

It's only bad publicity if it's accurate. Otherwise, it's an
opportunity to tell your side of the story and make him look bad.

--
Paul Robinson

Software R&D :: Unix/Linux :: Consultancy :: Open Source :: Comms
http://vagueware.com :: pa...@vagueware.com :: +44 (0) 7740 465746

Vagueware Limited is registered in England/Wales, number 05700421
Registered Office: 3 Tivoli Place, Ilkley, W. Yorkshire, LS29 8SU
Correspondence: 55 Velvet Court, Granby Row, Manchester, M1 7AB


Micah Martin

unread,
Jun 18, 2007, 1:01:44 PM6/18/07
to rails-b...@googlegroups.com
I'd recommend you be upfront and tell him that you'd like to end the
engagement and give him a month or so to find a replacement. Help
him find a replacement if you can. Then do your best to make sure
he's not left stranded when you do finally leave. Train your
replacement as needed. Document where applicable.

Micah

Greg Newman

unread,
Jun 18, 2007, 1:05:35 PM6/18/07
to rails-b...@googlegroups.com
I feel your pain Brian.  We've run into this twice before.
Luckily for us, we have our contracts worded so that either party can back out at any time.  We also have it in our contracts that payment is due upon receipt.  We're not a bank and won't extend payments to clients unless they are repeat and reliable.  I think Quickbooks has a credit check tool that you can use.  I've never used it so I can't confirm it's existence for sure.

If you feel it in your gut, go with it.  Show the client the door in a respectable manner.  Afterwards, take necessary steps to ensure your contracts are rock solid if they aren't already.  In the future, ask around.  Find out who else is dealing with the prospect and what their relationship is like.  This is easier on referrals and sometimes can't be done.

-Greg

Robert Dempsey

unread,
Jun 18, 2007, 5:21:03 PM6/18/07
to Ruby on Rails meets the business world
Brian,

Everyone here has a lot of great advice. If you are in the US, make
absolutely sure to check the contract you have with the client before
letting them go. Make sure that you fulfill any obligations you
(contractually) have to them, collect as much money as possible (the
fun part), give them advanced warning and perhaps pass them off to
someone you think may be able to handle them, or as proposed earlier,
give them a list of other companies they can work with. Firing a
client is always interesting business. Just make sure you are covered.
Good luck.

Sincerely,

Robert Dempsey
http://www.techcfl.com
http://www.railsforall.org

brasten

unread,
Jun 26, 2007, 9:21:27 PM6/26/07
to Ruby on Rails meets the business world
Hey Brian--

The advice given by others is great, just wanted encourage you to do
whatever you decide as quickly as reasonably possible. I spent
basically September-February working under circumstances almost
identical to what you've described -- by the time I fired that
particular client, I ended up not getting paid for over 3 months worth
of development.

I know, I know, how did I let that much work get done without
payment? Well, when requirements are extremely loose and everything
becomes an emergency and you end up wanting people to get people
'happy' so they'll pay, it happens much faster than you might think.

As everyone said, check your contracts to make sure you're covered. I
suspect it's also possible you don't have accurate contracts signed?
( I didn't with my client. One of those things we were 'going to
do'. ) If not, you may have to be prepared to walk away from anything
that's owed you.

Anyway, if you ultimately decide you have to get rid of him, get rid
of him quickly. I personally favor something along the lines of-- "I
have other interesting projects and personal ideas I need to work on
and will not have any available time."

-- Brasten

PS-- Yes, I did basically do every bad thing you could do from a
business perspective during that time (no/outdated contracts, kept
working despite non-payment, etc). Don't follow my example.

tmor...@gmail.com

unread,
Jul 7, 2007, 4:29:46 PM7/7/07
to Ruby on Rails meets the business world
On Jun 18, 8:24 am, "Brian Hogan" <bpho...@gmail.com> wrote:

> I'd love to hear how others have had to let a client go. What steps did
> you take to ensure a somewhat amicable split? When do you know it's time to
> let a client go?

It's just like employees:

"When you think you might need to fire someone, you should have done
it two weeks ago."

But..never fire a customer.

Raise their rates until they leave. Customers pay for the work you do.
If a client is causing more work than others, they need to pay more.

It's far better for an ex-client to tell someone "I used to use these
guys and they got too expensive." than "I used them and they were so
arrogant they told me to get lost."

--
-- Tom Mornini, CTO
-- Engine Yard


Brian Hogan

unread,
Jul 10, 2007, 8:29:18 AM7/10/07
to rails-b...@googlegroups.com
@Tom:
 
That's kinda what I was thinking. That's really interesting advice.

 

Jon Dahl

unread,
Jul 10, 2007, 10:41:05 AM7/10/07
to rails-b...@googlegroups.com
Tom's advice raises an interesting point. If you cut your price on a project - in other words, if you normally charge $80/hour, but agree to work on a project for $60 - then you can't really come back and raise their rate because they are being difficult. At least, it's a lot harder.

So try to avoid compromising on rate. If you need to compromise to get the contract, throw in a few features (like 30 hours of free QA or design), or maybe agree to build a small part of the site for free, in exchanged for code ownership. Better yet, of course, stick to your guns and don't compete on price. :)

Another way to fire a client is to get busy. If you are legitimately having trouble keeping up with all of your work, then the difficult client (who probably sees their project as more complex, critical, etc.) is the natural one to go.

Jonathan Dahl
Slantwise Design


Reply all
Reply to author
Forward
0 new messages