Let's assume since they've started to talk to you that they're already interested in your product and think it will do something positive for their company. That's the hardest part, so congratulations, you've gotten past the first part of the smell test. But now you have to help whomever is "sponsoring" you inside the company to convince others that it's ok to be working with a small company and this is the right thing to do.
So with that in mind, here’s our list of stuff we’ve developed over time to help us pass the smell test.
- Ability to competently facilitate an initial conference call and demo. Send an agenda ahead of time. Don’t be afraid to write an email before the meeting and ask some questions about what they want to cover and what their problem is that has led them to begin this dialogue. Know your demo well. If it’s easy, create some custom content for your demos that really give them the understanding of how your product would be used in their context. If you’ve got a little spare cash, get a subscription to gotomeeting or adobe connect or webex. If you don’t have money, use one of the free services. And try to have these conversations from a landline. A conference call they’ve gotten 7 people on their side to join and you keep dropping the call because your cell service is spotty from your house gets old fast.
- A mutual NDA that you can send. Typically they’ll want to use their own, but sometimes it’s just quicker to use yours and having one at the ready makes it feel like you've been here before.
- A well thought out and easy to understand price list for your business model. Having to talk through pricing or having a wordy email describing it will make it seem like this is the first time your product has ever been bought. Having a price list feels more professional.
- A 7-10 page slide powerpoint deck giving an overview of your company and product offering. Most companies typically ask for “follow-up” information to send to other people to get approval for your project and they want to be able to email something. For whatever reason just sending along a URL is usually not sufficient.
- Case studies: even if they are very general, it goes a long way towards making them feel like they aren’t the first to try your product. If you don’t have any yet, write up a generic one for a fictitious company and call it a "sample use case."
- The ability to offer up references at other well-known companies they've heard of. Don’t have any yet? Can you put out a public demo of your software for people to try out?
- White papers – anyone at any universities do any related research to what you’re selling that you can send as more background? If not, could you write a 3-5 pager that sounds relatively academic about the benefit your product is providing?
- A security FAQ. How will you manage their data? What precautions do you take against various types of exploits? What steps will you take if you’re hacked?
- Templates for service level agreements their lawyers or procurement teams can start to review.
- Well-defined and documented customer support process. An email inbox for all inquiries. A phone number to leave voicemail inquiries. Live chat. A knowledge base with a ton of information on it. A ticketing system. Just make sure it’s easy to understand how they get support. And keep it simple. No pay per request or anything that limits their ability to get help. If you have a well-built product, there won’t be a lot of support requests anyway but psychologically they’ll feel better.
- Application hosted at a reputable datacenter that is SAS70/II audited. We’re at Rackspace. Corporate IT has heard of Rackspace and knows they run a quality shop. The premium we pay to be there saves a lot of heartache. Corporate IT can be assured Rackspace is doing a whole lot of things process-wise, probably in an even more diligent fashion than at their own datacenter.
- SAML compliance or token services for use with their Single Sign-On credentialing system. Managing new usernames/passwords for a 3rd party app is like poison for lots of employees and just serves as an excuse for them not to use your stuff. 1Password and other localized credential management systems are not part of standard builds in large companies.
- An API: usage may vary, but knowing it’s there makes people feel more comfortable they will be able to expand and customize and integrate if/when the time is right.
- Well rehearsed answers to whatever negative conventional wisdom is out there about your underlying framework. We still get people telling us they’ve heard “Ruby doesn’t scale.”
- Ability to host a “sandbox” for them to try out before making any commitments. They love demos, but they also want to be able to try things out for themselves. Make this seamless and easy.
I’m sure some of this sounds old school and arcane, but that’s just the price of doing business with large companies. Some things can be mind numbing, but remember they’re not asking for this stuff purely to be pains, they’re asking because their procurement processes are designed to mitigate risk. The more you can do right from the beginning to assuage any irrational fears generated because you're a small company, the better. And besides, when it’s all said and done, hopefully you’re raising your glasses in triumph after winning that nice contract.