7 Tips for Selling Custom Kiosk Software

Selling custom software can be tricky in any industry and finding the right clients to build a long-term relationship with is always a challenge.

Custom software is typically expensive due to the lack of reuse (by definition, its custom) and potential clients often have a hard time grasping why their complex solution, with no off-the-shelf alternative, is so expensive.

When you deal with the self-service kiosk industry you add the complexities of integrating your kiosk software with kiosk hardware (payment devices, biometrics, etc…).

My goal for this article is to share some valuable insights on the process of selling custom kiosk software.  Craig Keefner @craigkeefner of Kiosk Industry was kind enough to collaborate with me on this article and together we came up with the following list.

Vet prospective clients by establishing their budget upfront

The easiest way to vet potential clients is to start talking dollar figures early in the sales process and see how they react.

Before throwing out any dollar figures make sure to invest the time to talk with them and really understand their requirements and goals for their project.  This can often be completed in an hour or less and will help you get a very broad idea of the project cost.

Once you have an idea what they’re wanting try to scare them a little bit by throwing out some large figures.  For example, “A custom kiosk application like you’re describing will probably run you somewhere in the neighborhood of $40,000 to $80,000 in software development costs.  Do these numbers scare you?”

The last person I asked this to laughed and admitted they had a total budget of around a thousand dollars (including hardware).

No amount of salesmanship on my part would have made this sale possible and the customer appreciated that I didn’t waste their time.

On a final note, if they ask you to be an investor, run!  This translates to “I have no budget and I want you to do the work for free.”

The greater the uncertainty, the broader the price range

When estimating the cost of a custom project there will always be some amount of uncertainty.

For example, the client wants to integrate their kiosk software with a piece of hardware which you’ve never worked with.  Sure you can review the SDK, but you still have no experience with this device so you’re just guessing.

This is why we do range estimates as opposed to fixed point estimates.  The greater the uncertainty the broader the range should be.  A great book on this subject is Steve McConnell’s Software Estimation: Demystifying the Black Art.

The customer needs to have some skin in the game early

By requiring the customer to make a significant payment early in the design process it forces them to get some skin in the game and ensures that they are serious about the project.

It’s easy to spend days or even weeks designing a solution for free only to find out that the customer lacks the funding to launch the project.

Take the time to understand the customer’s requirements and then create a broad range estimate.  Then require a 30% down payment before designing the project in great detail.

Once the project is well defined you can come up with a fixed cost, if you like, or just make the range narrower as uncertainty is reduced.

Reliability isn’t always worth the cost

This sounds funny but reliability is costly and it’s not always worth the investment, particularly when the project is a one-off proof of concept.

If the project is for an ongoing business that’s a different matter, but many times the customer just wants a prototype they can show investors to raise money or show their boss to gain support for the project.

If this is the case then with the client’s blessing you can shoot for “good enough” and get to market quicker with the understanding that rework will be necessary for scalability and robustness.

Distract the developers

Let me start by saying that I’m a developer and no disrespect is intended.

If the client has in-house developers you may find yourself stepping on some toes by creating software their developers feel they could create internally.  Never mind that they’ve never created a single line of code designed to run on a kiosk and they’re completely slammed with other projects.

Try to involve their developers in the project so they feel a sense of personal ownership by giving them little parts (distractions) to do.

If they can make some minor changes to the project they’ll feel a sense of ownership and defend the project as if it was their own.

When possible allow the customer to own the code

Don’t give aware your super-secret framework or anything but as much as possible allow the client to own the source code and IP.  They’ll appreciate that.

Invest in long-term relationships

There are some relationships that are worth investing in and that often requires biting the bullet by giving away your time for free on the front-end.

This is particularly true when dealing with larger potential clients.  I’m not talking about becoming an investor in some longshot project I’m referring to investing in a relationship that will bring you sales for years to come.

Hopefully the tips in this article will save you from making some of the same mistake that we have.

Please also checkout my article on How to Choose the Right Kiosk Clients – 22 Useful Vetting Questions.

Subscribe to our blog updates today to keep up to date on our latest content.