CHAPTER 12

Selling to Large Companies

Introduction

As you become better known in your niche and have acquired a couple of initial respectable clients, word of the company and product will grow, and the large players will get to hear about you. After a time, they will want to check out your offering for themselves. This is the time to start engaging with them. They will have no interest in your solution before this point. You are just too small and fragile.

There are two primary ways to land a large client:

“Land and Expand”

Winning a Request for Proposal (“RFP”)

RFPs are formal tender documents large companies use when they are looking for a new service. They are a pain and take a long time to complete.

“Land and Expand” is where you begin a small project for one team or location in a large organization. They are far easier and less soul destroying.

We will look at both in detail next.

Once you get seed funded and you start targeting the big boys in the industry, the thing that will kill your growing technology business is not the delays with funding, the endless juggling of cash flow, or the pain of trying to hire the best talent with no resources; it is the Slow No.

Remember that phrase. It haunts the dreams (and mainly nightmares) of many failed entrepreneurs.

The “slow no” is the long procurement cycle of most large companies. It is being passed endlessly from team to team, from IT to the procurement department and back to the operation teams once again, without ever getting a clear yes or no from anyone. It will take up months of company time and if not managed carefully can destroy your business.

Ignore the fancy PR from big companies about their fast innovation and partnerships with small innovative companies. The “no one was ever fired for hiring IBM” mentality still applies at most large organizations. Big companies are normally very conservative and slow to adopt new innovation. Their typical buying process can be from one to three years. It is extremely easy to get stuck indefinitely in this hamster wheel of indecision.

If your product is real, new groundbreaking technology that will change their business, you will face a second problem. You are going to have to educate them about this new technology and its huge benefits to their organization. You can get stuck working with their innovation labs for years, with nothing to show for it except a paid “Proof of Concept” product trial and with very little chance, they will put the solution into their “production” (i.e., live) work environment anytime soon.

Just like with your investors, to bring in a huge global company, you need to build up a great relationship over many months (often at least a year), while simultaneously working out a palatable commercial deal that they can digest internally.

Many of these organizations have strict rules about working with software vendors that have less than $10 million on their balance sheet and at least eighteen months runway in contractual revenue on their books. To get around these nominal roadblocks, you need to be clever and often start the relationship with a small, focused project (e.g., $50,000 to $100,000).

That is why it is key to sign up those couple of reputable, fast growing mid-tier firms in the industry, before going after the big guys. The references from these clients are invaluable at enabling you to jump some of these later hurdles. The big companies watch closely what the hungry, smaller players do. If they are at conferences or watching online marketing videos, where the competition they fear is raving about your product, you will find it much easier to open their door.

Selling Process to Big Global Businesses

I have the typical entrepreneur personality. This supposedly means I am predisposed to social encounters and energized by dealing with a wide circle of people. While this is basically true, nothing prepared me for the circle of relationships I would have to manage successfully, when trying to deploy our software at some of the largest global financial players.

You are dealing with at least three internal groups:

1. The internal sponsor—That is, the manager from the business itself, who is screaming for your product and wants it now.

2. The procurement team—Their whole job is to beat down the commercial deal you just spent nine months agreeing with your internal sponsor.

3. The technology team—The company’s internal IT department who often want nothing to do with you and are incredibly adept at making themselves unavailable to you for technology reviews. You are probably a threat to them. If your software is as revolutionary as you say it is, that’s even worse. Then you are even more of a threat to them.

Remember, for the Procurement team and the IT team, there is no upside to working with you.

That’s exactly why Intrapreneurs (what a joke!) at large companies don’t work. There is no real upside if things go right, but plenty of downside, if things go wrong.

How to Manage Objections

While you certainly didn’t set up the business to get into a form of “marriage guidance,” that is what you are about to have to do. Let’s be honest here. Most of these people at huge companies don’t know, never mind like, each other. Large, global organizations are the size of small cities. A staff of 100,000 is not that uncommon.

You need to find out who is the real buyer. Who controls the budget and who can write the check? In a gigantic organization, that is more difficult than it seems.

Longer term, when you are in the door and exploring long-term expansion and innovation plans with this keystone client, the secret becomes finding out who makes the budget.

Working With the Internal Sponsor

The internal sponsor is the person at the big company who loves your product and will champion the solution internally. You will need to work hard to foster a great, collaborative relationship with this person. That means drinks, dinners, travelling to business events to see them speak; all the usual requirements to build up a solid, long-term business relationship.

The initial deal will have to work to their budgetary requirements, and you should not let this first step be railroaded by your rate card. It is important to be flexible and evolve a genuine collaborative business partnership. A deep relationship will serve you well, when (not if) road bumps in the implementation project appear later on.

Quite frankly, you need to have the business sponsor in your back pocket. If you don’t, your exciting initiative will be lost in the fog of higher priorities, new crisis, and changes in strategy from senior management.

Managing the Procurement Team

The job of the procurement team is to get the best deal possible for the client.

They can be very painful for you and a complete roadblock to the project moving forward.

Put yourself in their mindset. They have nothing whatsoever to gain from the successful implementation of your product.

This means you need to negotiate carefully and structure the deal, so it looks like good value to them. Give them something that doesn’t cost you anything to sweeten the deal (additional training, some consulting, etc.). Perhaps tell them that you used to buy software before and know what unreliable vendors can be like.

Tell them explicitly you are happy to put in the contract that there will be no hidden charges whatsoever. Acknowledge that many software companies are notorious for this (like a drug dealer scam of getting the kids hooked cheap and then jacking up the price), and as demonstrated evidence that this is not your business model; agree that all additional fees and expenses outside of the contract have to be agreed and signed off by the client in advance. These can sometimes include random customizations they may request, a new report they want to build or travel to a far-flung regional office.

This can help put out the fires somewhat and take down the temperature of the negotiations.

Make the point to them, that unlike most vendors, you offer full and complete support over year ends, key holidays, and quarter ends. You will have to look at providing this. Many other small technology companies can only provide extended U.S. or European business hour coverage (i.e., 8 am–7 pm local time). That does not cut it for global organizations in the modern business world.

Ironically, key large company dates are often over business holidays (e.g., December 31st in the U.S./Europe and June 30th in Australia). I have seen technology business relationships get into serious trouble because the client had no one to call at 9 pm on a quarter end, when they were experiencing real technical difficulty. It is awfully hard to come back from that kind of disaster. Don’t let it happen to you.

Tell the procurement team that you will release updates every quarter and only seek to deploy it after written approval for evening or weekend access (if required). Any bugs will be reviewed and corrected when they give prior approval. You will not have any access to their private server or data unless it is provided by them for routine or requested maintenance.

Most easy of all, ask them for their standard vendor contract and try to make it global. It is much easier and faster that way. New offices can be brought onto the platform much faster in the future. The procurement team won’t even glance at the contract you used with your first client. The game has changed now. You are competing and delivering with the big boys and it has to be done on their terms, or you will go nowhere.

Be aware that many big companies now centralize their investment and purchasing decisions in their global headquarters. That means that the real money—the mid-six figure and above deals—are only able to be approved and signed off at these locations (e.g., New York City or in London). That is where the procurement team will also be based. These guys don’t know who you are. Moreover, they don’t care (“You want to spend HOW MUCH with this tiny software company we have never heard of ?”).

For us, being in Ireland, it was a problem. Local office approval for a project up to $100,000 was possible, but anything above that threshold normally had to be reviewed in detail and signed off by the procurement team. That team was inevitably based at the company’s global headquarters. For us that meant London, which thankfully was easily accessible. For you, it may not be that easy to get in front of the procurement manager. Their green light is essential to get the deal over the line.

The “Land and Expand” Strategy

Most large global businesses agree to new technology budgets on an annual basis and they mostly kick into place each January. Pulling this together normally begins the previous September or October. If your product is not included in that budget for January, it makes it extremely hard to get approval for a large technology deal outside of that annual expenditure cycle.

However, many departments and teams often have a smaller, local expense budget. This can be spent on ad-hoc improvements and smaller technology projects.

One way of procuring a large client is to get your product in the door initially under a small engagement. That way, it can potentially bypass the strict global company procurement process.

This model is known as “land and expand.” It involves finding a business sponsor for the solution and agreeing an initial smaller deal with them, under their own budgetary approval. This might be an initial $50,000 or $100,000 to try out the product within their department and test it for value and usability.

Once they have used the solution for a few months and are convinced of its merits, it is much easier to have it approved internally for a wider project roll out across the company. This process takes time, but is a useful incremental way to build a business relationship that is sticky and can be extremely profitable long term, once you perform as they expect.

With these large companies, it is all about de-risking the purchase process for them. The fact that you have a proven track record internally and have demonstrated that you are a reliable vendor is a huge step on the way to companywide implementation.

Set up your rate card so that the initial cost of the product fits within a smaller operating budget, while having significant potential upside as the solution is rolled out across the world.

This model allows you to ramp up internally on a gradual basis. It also gets around many of the “but this is a small company with a tiny balance sheet” objections that the procurement teams at large companies use to scupper start-up technology vendors.

Managing an RFP

Sometimes, there’s just no way around completing an RFP. This is a formal “Request for Proposal” issued by a large company, when they want to buy a new product or service.

Completing RFPs can be a good learning experience for your team, as you learn to understand and expect the key questions and level of detail, large companies require before they will even consider using the product.

Choose your RFPs wisely. You can’t possibly respond to each one. Completing an RFP properly can take at least a week. And most of these contracts, you will not win.

Set up an RTP database of questions you will always be asked (e.g., company history, investors, current clients, financials, etc.) and populate it gradually over time with good detailed answers to all the questions you are asked. Put them in different buckets (e.g., operations, legal, risk management, technology architecture, etc.) and add to them with each new tender.

Annoyingly, we found that each RFP was slightly different and the same area (e.g., procurement, technology) would often ask a variation on the questions we had answered in the previous tenders. There is no real way to avoid this. It’s a pain and all technology companies hate the RFP process.

It is far better to be invited into an RFP by a company you already know. Perhaps you have already met them and had coffee with them. Even better if they have already seen your product informally and know a bit about the business. Having some sort of existing relationship makes it much easier to find out what works for them commercially and what the key metrics are, that they need from you to make the contract work.

For large companies:

Short term—Find out who can approve spending from the budget

Long term—Find out who makes the budget. These are senior managers that can write the big checks.

The smaller players you have implemented to date do not have gigantic risk management and mitigation policies in place. They won’t have had dozens of data management and technology integration policies that must be adhered to. Your large new client will, and you will be expected to strictly comply with them.

It’s important that the commercials you agree to recognize the work involved in the implementation process. You may have charged anywhere between $10,000 and $50,000 to implement the solution at the first couple of smaller clients. For this first large player, you need to charge a substantial onboarding fee; certainly, well over $100,000. Otherwise, the economics just won’t work. You will need to hire new client relationship, technology, and development staff, to ensure a large client is properly serviced and resourced.

Managing Large Company Integrations

Once you agree to a big deal with a large company, it becomes a complicated process of managing existing clients, while simultaneously ramping up for your first large integration.

Managing a large global onboarding, when you’re only a small company, is a delicate balancing act. This means breaking down the client’s requirements, their locations, initial teams, key deliverables, and expected “ramp up” onto your solution and working out how best to deliver it.

Work with the project sponsor to agree on a realistic “Onboarding Plan.” That should spell out in detail the initial deliverables expected from you in phase one and the timeline around it. The client also needs to commit a project team or internal resources on their side to work with you closely on delivery.

In a large company, that can be more complicated than it seems. Many of their project teams will have fulltime day jobs, meaning they are probably terribly busy and not especially motivated by the extra work of onboarding your wonderful solution or the disruption it will bring to their lives. If they have specific resources to allocate fulltime to the product integration, then that is fantastic.

The first key item that needs to be agreed is the joint “Onboarding Plan.” Get ahead of the client on this. As soon as your team has finished celebrating winning the deal and your head is clear, draft a first version “for discussion” and send it to them immediately.

Use your original Implementation Plan as the template for this project. It will be too high level for a huge global project but the key areas (e.g., set up, training, testing, data import, etc.) will be the same and it’s a good starting point. Use the information gained in the RFP to begin expanding it substantially. This will make you look both proactive and professional. It is exactly how a game-changing relationship like this should kick off.

From earlier discussions with the client, or from the RFP they provided, you will have an outline understanding of how they want to onboard. It may be one office location at a time (or even one team). They may then want to expand globally, once that first location is bedded in. They may even decide they want to be more conservative and have their project team test your solution extensively, before then deciding to put it live in their real business environment.

A large onboarding project typically takes months and often a number of quarters. That works better for you, because it gives you more time to resource properly and address any teething problems that arise. Having won this deal, you will be playing catch up to expand the team quickly in order to service the contract. Having more time works in your favor.

Ideally, for a large client, the first quarter should be spent setting up the solution for them internally. This would include extensively training the first users, documenting how they intend to use your solution, importing any data and initial documentation for set up and then conducting extensive user testing in their test environment.

Having these first few months enables a number of dry runs of the software in their world. It also enables you to become extremely familiar with their internal processes. This is essential. You will have some idea from the RFP discussions, but a whole lot will emerge in the setup phase, that won’t have been discussed previously. New requirements, presumptions (by them), service demands, and particularly, data management and risk issues, all appear when they are spending real money with you.

Quarter two would then be spent on ramping up the rollout across the first office and beyond the initial project team. Training more internal users, addressing any teething issues and really bedding down the solution at your client internally. This will involve extensive relationship management, documenting any new business processes and agreeing a set of further technology functionality, they will likely request from the product.

While an onboarding process like this would be the ideal situation, with large companies, you are dancing to their tune and they will call the shots on the integration timeline they want. If it’s much too fast for you, all you can do is seek to counsel them from a risk management perspective and suggesting a more conservative onboarding schedule would be prudent. You can’t push back too hard at this stage; in case they get cold feet on the whole project. They are probably already out on a limb just by choosing your solution.

Your whole team must be laser focused on managing this integration. As the CEO, you need to appoint a dedicated project manager for the client integration. Not a relationship management or business development resource. An experienced software implementation manager who understands the steps involved in managing complex global rollouts and can anticipate and solve onboarding issues before and as they arise.

Build your own internal team to face the client and make sure, at the very least, it includes a project manager, an experienced technical developer, your product manager, the relevant client relationship person and a junior technical member of the team, to manage data and initial user testing.

As the CEO, you will have to be part of this integration team too. Ideally, you could leave the project manager to run things, but it is just too important for the future of the company that the project is a success. You will have to be heavily involved.

Depending on the resources, you may even need to be the dedicated project manager on this first big implementation. Once your team has done a few of these projects, then you don’t need to be involved day to day. Instead you can attend the weekly and fortnightly joint project meetings with the client.

First time around, however, it’s all hands-on deck. That means you. If the project goes badly and the client pulls the plug, you can forget about a Series A funding deal. It is extremely hard to come back from a setback like that.

The Role of Implementation Partners

One option to manage a project of this size, is to choose an implementation partner. In this model, your team manages the technology and your partner works globally, at the client’s various locations, to manage the onboarding and roll out. The large advisory and professional service companies are always keen to partner with technology vendors on projects of this size.

However, it is not recommended to use a partner like this for the first

big client onboarding. It is important for the team to learn how to do this themselves. You need to build up the internal knowledge base for managing these large global integrations. The ups and downs of the project will be a steep learning curve for your relatively inexperienced team, but it is nearly always the best way to learn.

You can consider an implementation partner for future enterprise level projects. This could happen because another new client demands that you send ten people to their Hong Kong office for three months to manage the rollout. If there are only 12 people in the company, this represents a big problem. Having the right local implementation partners can alleviate this problem.

Conclusion

The reason you are busy scaling the company globally, is to be able to get to the point where the business can seamlessly manage these types of large projects. This is where the big money comes from. The adoption of your software by many new offices will add massively to the bottom line, materially impact the next investment valuation, and can give you clients in every corner of the globe. At that point, your business is no longer valued in millions, but in tens of millions.

Chapter Summary

Manage all three core relationships at your first large client carefully—Business Sponsor, Procurement department & Client IT team.

Deal with their objections one by one.

Structure the deal with plenty of upside as use of the solution expands globally.

Charge the large client a hefty implementation fee to cover the huge cost in both acquiring and onboarding them.

Produce a draft Onboarding Plan immediately on winning the deal.

Push for a multiquarter implementation.

Consider an implementation partner for future large global integrations.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.222.196.175