How to lose a prospective client

Sonnenblumen

It is interesting to note and making interesting reading that a significant number of the threads in 'Design' appear to come from existing or prospective business offering web design/development service.

As someone who has been on the client side (more than once), I thought it might be helpful especially for any individual who may be considering setting up a web design business to get a broader perspective and some insights to running a design service. Often cost estimating, charging for services crop up but besides the usual focus of castigating competitive pricing models as little more than a 'race to the bottom of the barrel' etc, there is little debate on the content of what a viable commercial business strategy for a web development business might or should contain?

Determining an appropriate strategy will demand that several factors be considered including creativity, skill sets, competitiveness, experience etc Some of these might be considered subjective but there are indisputable objective factors worth considering.

An interesting one might be for previous or current clients to offer feedback to would be vendors of what designers might/should consider and avoid the risk of losing a prospective client.

So for example to kick-off:

Bad Housekeeping - poor or late response, usually manifested by slow follow-up to calls, long delays in submitting paperwork, quote etc especially when the timeframe was proposed by the vendor.

Verdict: the last thing a client wants from a service provider is no service.
Result: No sale (no matter what the other factors might indicate).

The Corinthian

Lazy tender responses. I've consulted for clients tendering out substantial projects in the past, and it is amazing the poor level of responses you get. So the prospective client client sends out a request for tender (RFT) and the responses begin to come in and you begin to see repeatedly some of the same mistakes:

Generic Marketing Brochures. Essentially, you get a big response document, of which less than five pages actually constitutes the actual response to the tender request. The rest is marketing filler; portfolio examples, case studies, generic blurb on vision and methodologies, and so on. If you're reviewing tender responses, you're going to focus on how they respond to your requirements and ignore the rest in the first round of reviews, and if all they do is a few pages, buried in a mass of generic marketing blurb, I can guarantee that your response will end up on the 'no' pile very quickly.

Failure to Actually Respond to the RFT. Possibly the single biggest mistake I've seen in responses is they don't actually respond to the RFT. I suspect this is because they don't actually read it very carefully, but as a result you'll get responses that may address some of the RFT requirements, but not all, and/or some responses will ignore specific requirements (e.g. RFT says that it wants to use a dedicated server hosted in-house, to which the response talks about hosting in the Cloud). To add insult onto injury they'll add in new requirements in an attempt to impress you (and generally upsell some skill-set or service they specialize in). Another one for the 'no' pile.

Bad Pricing and Obvious Honey Traps. Be careful with your pricing - when doing a breakdown, it doesn't take an IT professional to hear warning bells when they see that you're estimating two days for a basic 'contact us' form page/handler. Additionally, many Wevdev companies include 'honey traps'; low-ball quotes followed by a change request structure that is clearly designed to bleed the client dry the moment there's a problem or change. If you're lucky, the client won't notice this, but at the same time don't underestimate clients as many will identify such traps and/or be getting advice from someone in the business who can. Either way, bad pricing and obvious honey traps can lead to an immediate loss of trust, as it is clear you're looking to screw the potential client, and a one-way ticket to the 'no' pile.

Amateur and Unreadable Responses. Use the spellchecker, FFS. If you're numbering pages, make sure they correspond to the actual pages they refer to. Make your diagrams professional (use something like Visio rather than MS Paint or Word to do them). If you send an electronic version of the document, do so as a PDF, not a word document (with the document history still embedded in it). Make the document clean, well formatted, easy to navigate and read. If your response is amateurish and sloppy, then that conveys that your firm is too and again it will find itself in the 'no' pile - and not even be read.

Anyhow, where it comes to responses to tender, these are some of the more common mistakes, off the top of my head.

Sonnenblumen

Well done Corinthian. Must admit I wasn't sure it was me but why do some companies insist on submitting a proposal in which 80%+ of the content h is pure advertorial agency profiling material.

Of course it is important for the vendor to communicate competencies etc, but does a proposal need to be heavily skewed towards advertorial content? I think not.

Not only is it a gross imbalance, it also suggests a very formulaic approach to preparing individual proposals, which might be also be counter-productive? By all means use a template but do so with the obvious common sense too would be no harm.

At least try to impress on the prospective client that a bespoke proposal has been prepared and not some regurgitated file with minmal amendments?

ChRoMe

The Corinthian wrote: »

low-ball quotes followed by a change request structure that is clearly designed to bleed the client dry the moment there's a problem or change.

Thats a two way street, on nearly every god damn project I've seen the client attempts to fundamentally alter the functional specification and then pleads innocence when its raised.

Those change request clauses are vital to protect a suppliers margin. I'd never apologize for a strict change request process.

The Corinthian

Sonnenblumen wrote: »

Not only is it a gross imbalance, it also suggests a very formulaic approach to preparing individual proposals, which might be also be counter-productive? By all means use a template but do so with the obvious common sense too would be no harm.

It's always going to formulaic, more correctly working off a template, to a degree; it's not economically viable otherwise. After all, were you to do every one from scratch, how long would it take? And of every tender you reply to, how many contracts will you bring in? Viable if it's one in twenty (each taking five man-days) and that one is worth €200k, otherwise you're going to be out of business pretty quickly.

Generally, at a basic level, I'd break it down, in order, thusly:

Cover. Template. You'd be surprised how many don't bother with this.

Introduction/Forward. Custom. This is where you show the client that you understand what they're looking to do and why overall. This first impression is important as it can create a very good impression before they even get into the document and assure the potential client that you're on the same wavelength and you've taken the time to understand what they're looking to do.

The response. Custom. The most important section, and should be the single largest one - to the point that I'd cut down other sections so that they don't dominate the document. What is important is you answer the RFT, all of it, as clearly as possible and only the RFT. That's what they want, not add ons that you can offer but they've not asked for and not a full project plan or technical specification.

Breakdowns. Both custom and template. If asked for, you may need to give a breakdown of how long different parts of the project will take. This should be in table form, only as detailed as the RFT has asked and can be based on a template, but with custom details.

Fees, legals, etc. Template. Hourly or daily rates. How change requests or issues are defined. SLA terms and rates. Response times. Bare in mind, these may be overridden by the RFT requirements, so they should always be double checked for consistency with what's written in the response - I once saw a response that said one thing about the SLA when specifically responding to the RFT, then something else in another (cut 'n pasted) section.

About the company. Template. This is where the marketing blurb comes in; telling the company about you and your resources. Best option here is to have a lot of marketing material and then ruthlessly delete everything other than the most impressive and relevant bits.

Appendices. Both custom and template. Anything that doesn't quite fit in the rest of the document. This is where I'd include anything I'd want to up-sell to the client or administrative stuff like document version history.

A lot of the above is still pretty formulaic, but it emphasises and clearly addresses the client needs and so does not look too formulaic in the end.

That many tender responses end up becoming packed with marketing material is probably down to there not being any real sales strategy, resulting in a document that has grown organically and bloated over time as more and more marketing material has been added to in an effort to make it look more 'weighty'. Instead, it looks crap.

ChRoMe wrote: »

Those change request clauses are vital to protect a suppliers margin. I'd never apologize for a strict change request process.

I accept what you're saying, but that's not what I was talking about. 'Honey Traps' are essentially low-ball deals that lure the client into a contract designed to screw them in the long term.

We've all started contracts with clients that we know from the onset are not going to read through any specs we send them before signing off, for example. The ethical way of dealing with is by offering a prototyping approach, in addition to the spec and actively walking them through everything before they sign off. If you don't, you know that pain will soon follow, in which case extra costs will be charged to cover you.

Instead, you can offer to develop whatever it is using an agile evolutionary iterative process and bump up the price of any iterative cycle T&M. Unethical, but it'll make you a lot of money.

I saw this done with a pretty basic brochureware (a custom CMS, ASP+MSSQL, Flash - nothing special) site, for a bluechip consultancy. They were going to be a difficult client and we knew this from the onset (their PM changed a half-dozen times during the project, for example). So we set a honey trap. Final billings; €185k.

ChRoMe

The Corinthian wrote: »

I saw this done with a pretty basic brochureware (a custom CMS, ASP+MSSQL, Flash - nothing special) site, for a bluechip consultancy. They were going to be a difficult client and we knew this from the onset (their PM changed a half-dozen times during the project, for example). So we set a honey trap. Final billings; €185k.

185k to a Bluechip sounds about right, I wouldnt consider it a honey trap. The correct price is the one that the customer deems to provide value.

One of the sites I work on, its monthly maintenance bill is 90k. Thats basically for copy and image updates.

The Corinthian

ChRoMe wrote: »

185k to a Bluechip sounds about right, I wouldnt consider it a honey trap.

Trust me, it was a rip-off. We're talking something that wouldn't even cost 10k normally and even with the added administrative bloat of your average bluechip, it still wouldn't have come to 50k.

ChRoMe

The Corinthian wrote: »

Trust me, it was a rip-off. We're talking something that wouldn't even cost 10k normally and even with the added administrative bloat of your average bluechip, it still wouldn't have come to 50k.

Thats a bad way to look at it. Did you deliver what was required and the client was happy?

If the answer to both of those is yes, then it wasn't a rip off.

The Corinthian

ChRoMe wrote: »

Thats a bad way to look at it. Did you deliver what was required and the client was happy?

I wasn't involved in the final sign-off so I don't know how happy they were.

However, even if they were and the eventually got what they wanted, it still does not make it ethical to deliver something which you know you could have delivered at a fraction of the inflated price you ended up charging them.

Just because you're happy with what you got, doesn't mean you don't know you were scammed. It just means you haven't realized you were scammed.