Archive for category Sales
I would like to continue topic of Expert Sales. See previous post – “Expert sales: part I – assessment“.
It covered decision making model when launching expert sales. But how to get there? How to retrieve those answers from your client?
Let’s make first very first step – first talk or meeting with your customer. Dealing with front-line requests you never know who is calling you/who is at your door, so need to act prepared in order not to miss your chance.
Let me take an example…
Imagine you have your phone ringing and a nice female (or male, your choice) voice asks for your service. What would you do? What questions would you ask? What and how will you tell/offer? What would be your next steps? What impression will you make?
First of all: make sure person who is speaking with newly called customer is qualified enough to start assessment. If not, leave clear instructions how he/she should act and what to tell/not to tell if such a person is unavailable at the moment.
I usually leave clear instructions if call reaches receptionist and no one from sales guys is available:
- Register person’s name, position, contact phone, e-mail;
- Ask how he/she learned about us?
- Ask to describe what service he/she is looking for?
- Ask what company he/she represents?
- Agree for suitable callback time of sales person.
Be cautious and NEVER at this point:
- Give any estimations on time, budjet, etc (even if person insists);
- Start “selling” yourself or your services/pushing/advertising;
- Say NO (after a while you may establish clear rules when you allow your front-line guy to say NO to assess already at this step);
Benefit applying such an approach is that that your sales guy will have time to prepare and gather information before the call, that could be:
- Surf client’s webpage/Google about company, their services and business;
- Analyze initial request and perform first step assessment if possible;
- Prepare questions you would ask to assess further;
- Obtain information about possible competitors of potential client;
- Obtain information about person you prepare to call to;
- Call back when ready and as agreed;
And finally, remember: you never get a second chance to make a first impression!
And whoever plays in your front line he/she makes that impression.
To be continued…
I define those as: an action to convert new customer (client) to sign a contract with us (supplier) on whatever is non-existing (thus not tangible) yet, that needs to be developed and require high expertise both to develop and sale.
Topic is specifically important for companies providing software development services. Because those usually do require such an expertise and cost a lot.
To be clear: I mean selling services that require high expertise. I do not mean goods or typical or cloned/a bit modified software that is relatively easy to implement that require different methods of sales.
Real life example
Let’s take real life situation to explore challenges and ways to address expert sales in more details…
Imagine you run a web studio or software development lab as a sales manager. Your goal is to provide it with required level of contracts per month (quarter, year) to generate required first sales.
Imagine also that your marketing works well and you have incoming pool of customers with initial needs at your door, phone, e-mail, etc.
What shall you and your sales guys do to get them converted in? And how you ensure you’re converting right ones?
This post addresses the second topic.
Implementing expert sale assessment
Expert sales are hard to implement, as those require a lot of energy, ‘cos you may need to “chase” desired client quite a long time, but it pays off in the end.
To ensure that it really worths, you need to be able to “filter”. Because you’re about to invest into converting this customer, so you need to be sure you have reasonable ROI. Surely you have your view what products your company/department is targeted best at and where you see your biggest margin. You also know how you prefer to work and what working conditions are most suitable for your team. And many other factors you know better…
Your fist goal will be to filter all incoming requests leaving those that are not compliant out.
Things that I used to assess (building up a scale) of worthiness:
1. Client organization portrait: big/small, long/short term oriented collaboration, start-up/grown, etc.
2. Who is our first point of contact: this reflects two things:
- how serious client is about upcoming project (how much time he/she is ready/planning to invest and to what extent be involved);
- and who in person is your possible counterpart (this also reflects what aspects of possible project are considered as important by client);
3. Project characteristics: scale, suits our possibilities/have to involve subcontractors (freelancers), long/short term, etc…
4. Level of readiness: to what extent client is ready to invest into new project immediately? Does client ready-ready or just “thinking” to start project?
5. What is decision making structure within client’s organization of contracting with us: who are key people that will participate in deal from client side? How they influence yes/no decision? How potentially problematic it may be to work with/persuade them?
6. Product management: to what extent client knows what they want? Will project also require product management expertise from us? Is it acceptable for client? What will be outcome of the project if product management is needed but client will not let you do it?
7. Project management and possible collaboration ways: as we used to/non-acceptable, have to accommodate to client needs?
8. Risks: all kind of things that look odd and/or suspicious;
Only after having those questions addressed you can make decision about investing into “expert sale” deal. And there are poor chances that you’ll get answers to those questions if ask them directly. You need to discover them for yourself, gradually…
How? This will be a topic for some future related post.
To be continued…
From the fist look Agile may be obviously beneficial, however getting customer there is not that trivial as it may seem to.
Let’s take an example I’ve came across recent times.
An online service wanted to have new web application developed (for certain reasons I cannot specify it’s name). It turned to a team, giving high level detailed specifications and asked for estimates (both budget and time-wise).
Or another one: “… we’ve got budget fixed and cannot afford us more. Can we get our application for it then? How we can have guarantee that we’ll cover key functionality we need, ha?”
Or… “Just tell me when it’ll be ready and how much it’ll cost”.
Well, the scope is usual trap here. Customers may have a rough idea about scope (in some cases they could have even detailed specs defined). In both cases it ends up having either nothing specified or too much specified making them hardly answering realistic scope question and leaving team being not able to forecast or making dangerous guesses.
Familiar cases, aren’t they?
To address situations like these I combined my sales experience with known Agile benefits and came up with simple 10 step practice.
Here I go…
To get the point how to sell best it’s needed to get closer to the reasons why your customer demanding to have fixed contract: most likely he may want to be sure he will NOT spent more budget or time then he has in mind to to get the imaginary scope. There may be plenty of other reasons as well…
Only getting answers will help you to prepare your deal properly.
Here are simple steps I found working dealing with fixed contracts:
1. Prepare (before you start): think of the reasons and ways to make sure you understand limitations and rationales for fixed contract for your particular customer. Stop here and think!
If you’re not sure you understand those, do not sell as you’re not prepared yet and you may offer wrong benefits, operate using wrong terminology, stress not important aspects, etc… This is key point. Prepare your deal before moving forward (I promise another post to explain how to get clear and move forward).
2. Set the stage: explain Agile (SCRUM) rules without selling them at this point (just simply telling how it works and what it looks like process-wise from customer perspective). It is important that at this point you still do not “sell”, just take time to explain Agile. Get feedback cautiously and to see if customer gets it. Continue explanation until he gets a full picture and feels confident with “mechanics” described. It is also important not to overdo it: it should be easily understood, sound light-weight and non-technical at all;
3. Step forward: offer first planning session for free (this works). This will help customer to both get more involved and feel more secure moving forward. Explain that by this you’ll mutually try collaboration with each other “softly”.
4. Involve (offer help): some clients want to (or like to) develop specifications on their own, some want to have contractor or 3rd party side PO doing this. In both cases customer needs some help getting started with story writing as it requires knowledge and practice.
5. Agree on conditions of satisfaction of each feature (aka Definition of DONE), since it will have an impact on estimations. Do not be technical here if you deal with business people (or be if you asked to explain it to CTO or a tech guy). Again be cautious here: some tech guys have their own opinion on what is important (is not) that is hard to change (and also wrong). It may be that you end-up knocking into the closed door if you start offering without asking what is considered as important first place.
6. Follow up after first planning session by helping to re-calculate to contract details:
- story points to time, knowing team baseline (assuming established team with agreed baseline of estimation);
- sprints required (knowing team average velocity) to the budget required;
It may be required to estimate entire scope. There are known techniques to do so. Goal here not to be exact (since you’ll never be) but to create feeling how much features customer gets approximately for a single sprint budget and/or how many sprints it will take to cover entire project. Usually this impresses (because Agile teams are way more faster than others). Then move forward and SELL!
7. Sell: stress that with Agile business is riskfree, since your customer will:
- avoid big-bang integration and “surprise parties” (by releasing as early as possible);
- observe potentially shippable software every sprint, having all required qualities-in (DoD);
- be able to adjust what features are most beneficial per sprint and ensure that team working on top important ones;
- be able to get end-user experience early to steer the product in the optimal way further;
If you’ve done everything correctly already here you should have READY customer. But he’s not fully there yet (or still has some doubts). Stop. Ask for doubts directly. Take your time to explain. Continue until all doubts are addressed. But you need a final “stroke” make customer feel more confident.
8. Pause (optional): there are two options how to continue at this point.
- Let customer “sleep over” with everything above (I usually do that), but it depends on what extent is your customer “boiled” here. Short waiting is good, because it lets sale process within customer’s organization to take place (aka “inside sale” stage). Involved managers discuss here and come to the point to sign/not to sign contract with you.
But here’s the trick I apply: you should try to know by when decision shall be made and act a bit up-front in time (#9). Because if decision is made it may be too late (in many organizations it usually is).
- Continue if you sure customer is ready for another “strike”;
- option to terminate contract at any time after sprint review session (with some benefits for you, of course).
- option to swap features and do changes in scope at any planning session.
10. Close your deal.