Winning And Keeping Corporate Clients
Posted on 17 Dec 2002
by Martin Burns (MartinB)
Rated 3.89 (Ratings: 0)
- More articles in Site Development
This isan article about selling to medium and large organisations, based on both selling to, and buying for corporate clients, and making sure that all concerned are happy about the result. The amount of work may not be that large (although the daily rates are attractive), and you may only be dealing with a small department or offshoot, rather than directly with the behemoth, but whenever you're dealing with work for a corporate client, the rules are pretty similar. Actually, many of the behaviours you need to show will also make life easier if you're selling to smaller organisations too, so don't ignore all this because your market is SMEs.
Corporate is different
The main difference betweenCorporate clients and non-Corporate ones is not size, but the level of organisational complexity involved. I've worked on a job where the client was under 20 staff, but they answered to an industry consortium made up of a number of competitors. The job may be extremely simple (and in that case, it was), but to win and keep the work, you need to understand that the organisation who's paying for it is complex and needs to be handled in a way that respects and responds to that complexity.
A number of the approaches below may strike you as absurd, wasteful andcalculating. A priori, they are. But you need to think in this way to keep the money flowing in. If you reject what's below in principle, condemning it as management speak, you're probably right. But that's the point. If you're targeting Corporate clients, you need to speak the language — understand the code, play by the rules — that Corporate clients live by. And as they're the ones with the work that you want, it makes sense for you to make the compromise.
But why would you bother?
Because that's where the workis. Not only are Corporate clients the source of most jobs, they're also the source of the best daily rates — they pay professional rates for a professional job, and they're likely to be around next month when payment's due.
The most important difference:
The person you are selling to has to justify the time and moneyinvolved to stakeholders (including but not limited to bosses) who you won't meet. They will look sympathetically on anyone who will them help to do this with the minimum of stress on their part.
If you understand this, and are prepared to work with it, 90% of what'sbelow will flow naturally.
Getting the Work
Who is the Buyer?
This is perhaps the biggestmistake that inexperienced people make in selling to corporates: they assume that the client member of staff they talk to can make the decision on their own. In nearly every corporate environment, many people influence the buying decision, with varying levels of influence. The person you're talking to may not even have a significant influence; they may be easily over-ruled by other stakeholders with different objectives.
So rule number 1: Findout the stakeholders and their likely agendas. You'd expect those agendas to be simple: good work for low cost. But it's not that simple. Every stakeholder will have their own private agenda too. Obstruct that private agenda and you'll have difficulty gaining their support.
Here's an example of a typicalset of stakeholders, laid out in a way which makes it easy to quickly devise and stick to a plan of attack. It doesn't address their inner personhood, but it's about winning business, not lifelong friendship.
The scenario is that Paul hasput your name into the pitch process for the work his team needs because he's seen that another site you've done does something similar to what he needs.
|Name||Attitude to us||Influence||Role||Personal Agenda||How we will satisfy it|
|John||Indifferent — also uncaring about who gets the work as long as it's good work||Low|| |
We need a tick from him to reassure managementthat our work will be up to quality.
|Needs to be confident that our work is up to quality, plus wants to be able to show off the site to his evolt.org(!) mates||Reassure him that the site will be standards-compliant, usable, accessible and lickably gorgeous|
Works in the team that will benefitfrom the site.
We need him to be actively pushing us
|Wants to be given a project to star in||Subtly position him as the natural leader of the project or an element within it, and help him do it successfully, even if it means crediting him with work we've done.|
|George||Somewhat negative — would probably prefer DIY||High||Manager of the team that'll benefit from the site.||Needs to be comforted that the work will be completed to time and budget to maintain credibility as an effective manager||Emphasise our professionalism in project management skills — all negotiations handled well, with quality written documentation (check the spelling with a fine tooth comb!)|
|Ringo||Negative — isn't convinced that our work is best value for money||Medium|| |
We need a tick here or the budget won't getsigned off.
|Wants to show how tough he is to senior management.||Make our initial quote on the generous side, allow ourselves to be beaten down to a fixed project budget. If possible, make our final invoice a bit under budget|
So out of all this lot, who'sthe buyer? Well they all are, but only Paul needs to actively choose you to do the work. Everyone else has merely to be reassured that you won't screw up. Fortunately, Paul is already on your side, so you need to keep him there while moving everyone else to at worst being unable to think of a good reason not to use you. And if you give everyone a boost to their own personal agenda, they won't try that hard to look for that good reason.
RFPs — Answer the Question
In ideal-world, all you haveto do is show the potential client your portfolio of work, submit a quote for the work you're pitching for and wait for the call to start. But it rarely happens like that, and understanding what happens during the 'wait for the call' stage can be very helpful in getting the work.
Normally, a corporate clientwon't have a completely nailed down set of requirements at the point that it finds an agency to do the work. What they'll often do at that point is issue a Request for Proposal (RFP), which is a document which is the bones of a brief, laying out what the current business objectives of the project are. In responding, the agency must put together a best guess outline of the how they intend to go about delivering those objectives. The successful agency will then work with the client to nail that down in detail.
In assessing the responses toRFPs, the client is trying to work out a number of things:
- How well does the agency understand and seem capable of supporting our wider business objectives?
Sitting behind the brief is the environment that the buyer is sitting in. Above and beyond the specific needs of the work set out in the RFP is the larger needs of the organisation. If the RFP is for a site to keep lots of conflicting interests informed and supporting a major project, will you as an agency help that process? Or will your behaviour make that harder by having opinions which are visible and upsetting to one of those interests?
- How well does the agency fit with our industry and organisational culture?
If the site is for a banking client, will they embarass us by turning up in skate gear and talking whizzbang jargon we don't want to make the effort to understand? At a basic level, can we form a mutual respect so each side can understand and respond to the other's needs?
- How well does the agency understand the brief?
The RFP will be written to support a set of business objectives and have a set of constraints — both organisational and technical. No matter how firmly you believe that a Linux/Apache/PHP/MySQL solution is the best solution for the type of site in question, a client with an all-Microsoft architecture isn't buying. You may feel that a client is best served by a content management system, but if they don't have the staff time to update the site and would rather brief you to do it for them, you've wasted your time proposing anything else. If the solution proposed by the agency doesn't actually deliver an appropriate solution or show that the agency could deliver a workable solution given the full facts, the work will go elsewhere.
- How competent is the agency's work?
This is largely based on an agency's portfolio — demonstrating that the end result is fit for purpose.
- How capable is the agency of delivering the project?
This is a key project management question. The agency needs to demonstrate that it will deliver on time and on budget, and — most importantly — ensure that management are reassured that this is the case at all times.
- What's the estimated price?
This needn't be an absolute firm price at this point, as the RFP still isn't a full requirements spec. Either an estimated total, or a pricing model could be enough. How and when you're going to bill the client can also be significant.
Which is the most importantto satisfy? Which can the buyer let slip a bit if it comes down to a choice (and no agency is perfect across all areas)? It's easy to assume that you must demonstrate elegant solutions which look lovely and satisfy all the standards known. And from a pride in your work point of view, that's how most of us feel about it. But past a certain level of "Good enough", that's rarely the case.
Look back at the stakeholderchart above. John has a low influence — and that's typical in corporate projects. The highest influence will nearly always come from the traditional suits — the senior manager and the budget holder. In the vast majority of corporate project sales, delivery outweighs talent because talent is common, and talented mavericks are just a pain to explain to the boss. The rare and valuable creature is the one who when they say they're going to do something, actually does it.
On the other hand, don't expectthat the lowest price will automatically win. The thing that the budget person is looking for is that it's in the right ballpark, or could be once the full requirements are defined and the budget negotiated. Quoting too low will raise questions over whether you're cutting corners, so it's important to know what the client expects the going rate to be for the specified amount of work. Once you understand that — and know you can still make money — then you know what to quote.
Keeping the Work
Congratulations — you'vegot the contract! You've worked out a final spec and price and have started on the job.
Now how do you keep it? And as the newly incumbent web agency, how doyou use this position to gain more work? It's all based on how much the client trusts you.
As we've already seen, the best possible thing to do to a manager isto deliver what you promised, when you promised it and for the price you promised. Consistently do this, and you'll get a reputation for reliability — your client's project manager can make promises based on your word and know that the promises are good. Project managers thrive on this kind of stuff: it's what they get rewarded for, and as you now know, supporting personal agendas gets you sales.
Conversely, the worst thing you can do is spring nasty surprises on them,because then they have to explain to their stakeholders that they can't deliver their promises without the benefit of having prepared the ground first — the hassle goes on up the chain.
Everything you do on the job needs to be aimed towards buildingand maintaining your client's trust in your ability to deliver what you promise.
Manage Expectations (aka Cover Your Arse I)
At all times, you have to bein control of what is expected of you. It'll come as a pleasant surprise to learn that clients do understand that sometimes things run late or over budget, provided they know about it and are reassured that you're doing what you can to bring it back in line. If they know about the possibility early enough, they can plan around it, and make sure that their stakeholders don't get upset about it. But the key is that they have to have accurate expectations, which they will base on what you tell them.
At all times, you have to beable to tell your client project manager how you're doing, compared to where they expect you to be (aka the Project Plan). They may not require you to submit monthly, weekly or (heaven help us) daily progress reports, but if they ask you for the information, you have to be able to answer within a day or so.
Most importantly, you have to proactively tell your client project managerwhen you're going late or over-budget, by how much and what you're doing about it. You need to do this at the earliest opportunity: as soon as you think it's a risk.
This means that you're alsogoing have to have a very strong project plan, separate from the one that the client holds — usually in more detail. This should be based around what you need to deliver to clients and be 100% clear how you're doing against it, including best and worst case outcomes. And to get that, you need accurate information from everyone working for you. Unless you're absolutely against deadline, having progress information to hand is more important to keeping client trust than doing the work. You need to be on your staff's backs about this to the level of near fascism because it goes against the natural grain of nearly all developers, designers and writers (this is why agency account directors have authoritarian reputations).
It makes sense to formalisethis — make it a regular appointment both with your team, and with the client and get absolutely everything documented in writing in more detail than you expect to tell the client. That way (a) you won't forget (b) you can respond to client requests for more information (c) the client can't complain that they weren't told about any likely problems.
Manage Changes (aka Cover Your Arse II)
Show me an agency who hasn'thad to cope with changes in their client work and I'll show you an agency that doesn't have a portfolio. It's inevitable that changes will come along. If you hope to still have the contract afterwards (and ideally, charge for making them), you need to have everything nailed down tightly.
Repeat After Me: "It's Not In Scope"
The very first piece of work (chargeable, ideally) you should do is todefine the requirements of what you're agreeing to do. This will be the basis of your final contract, and will let you calculate the exact time and cost you'll need to do the work. Once that's agreed and signed, then you can start work proper.
However, once you've started, it's inevitable that the environment willchange (usually at the order of one of the stakeholders you can't influence), and your schedule of work will change along with it. This can go in one of two ways - more work (and the same size job built differently is nearly always more work) or less work.
If it's more work, the mantra you need to repeat until you can reciteit in your sleep is "It's not in scope," which means "we didn't agree to do that in our original time/budget exercise." The outcome of this should be a renegotiation of the time and/or budget involved. You'll need to work out what the difference is, and the client will need to formally accept that so that it becomes a variation in the contract. This needs to happen before you start any work on it. Otherwise you're doing work that the client hasn't contractually agreed to, and your chances of being paid for it are limited.
If it's less work, you may have the choice of demanding the money anyway.But the breakdown in the client relationship involved is rarely worthwhile, particularly if you want to sell to them again. If you've built the right relationship with the client project manager, they'll be feeling angry about it too — particularly if they have the same personal needs as Paul above. As well as being upset on their own behalf, the client will also likely feel that they owe you one. So stop and think of an outcome which is good for both of you, such as a committment to (or at least a sympathetic opportunity to pitch for) another unrelated piece of work.
In either case, it's useful to put in place a process for managing changerequests. A change control process can be formal or informal, related to the size of project, and may have different levels of formality and signoff depending on the impact of the change. But the bones of it will always be a description of the change, a benefits statement, an assessment of the impact on time and budgets, and signoff from both client and agency.
"I Serve at the Pleasure of..."
It should go without sayingthat all changes to the site need to be instructed by the client. They own the result, and pay you to make that result the way they want. If you disagree with the client on what this should be and how it's best implemented, it's fine to challenge them. But it's not your decision in the end. Ultimately, the client has to sign everything off and you will rarely get paid until that happens.
This also means that if youmake changes on your own initiative, don't expect to be able to bill for them. If the client tells you to make the 404 error page a duplicate of the homepage, by all means demo a better alternative. But if they don't go for it, the time taken to change your demo to their instructions isn't client billable (unless otherwise agreed).
Manage Risks (aka Cover Your Arse III)
There will inevitably be a list of things which could go well, or badly,and that you don't have control over. The thing to do is make sure the client is aware of them,so there are no nasty shocks, and your plan for dealing with them, so they have confidence that you can cope if they do turn out that way.
As with progress reports, you need to keep a register of these separatefrom any register the client keeps. At a minimum, for each one, you need to know:
- What the result could be
- How likely it is (could be a rough percentage, or a simple high-medium-low)
- What impact it will have if it happens (both in detail "the result is x" and summary on a simple critical-high-medium-low scale)
- What you're doing to reduce the likelihood of it happening
- What you plan to do to reduce the impact should it happen
To help you take it all in in a glance and concentrate on the importantones, most projects use the the probability and impact ratings to produce a simple red-amber-green rating for each one.
When Do I Get Paid?
The short answer: when the client signs off onyour work.
The longer answer: at stages set out in the contract,usually based on milestones (eg "When we have a site structure" or "When the site is live") in the project plan. The client needs to formally accept that the milestones have been reached — this should be in writing. For the site go-live, it's inevitable that some measure of UAT will be involved.
Getting work from the Corporate sector isn't impossible. Keeping thework right through the contract and onto the next sale isn't impossible. Both need a broadly similar approach to the one traditionally taken by independent developers:
- work out your stakeholders
- work out their needs
- build the relationship by responding to stakeholder needs
The difference is in what those needs are and how you respond to them.You'll need to talk differently and behave differently to reassure your stakeholders that you can help them manage the complexity of their environment.