The Problem With Playing In A Software Sandbox
How do you vet a third-party vendor solution? If the answer is asking to test out the product in a sandbox, then you may want to rethink it.
A sandbox is a sample version of a solution pre-populated with generic data that allows potential users to explore its functionality. On the surface, it may sound like a good idea. After all, you test drive a car before you buy it.
But using a sandbox and test driving a car are very different things. A test drive accurately represents how a car looks and drives and how it fits you. You can apply what you already know about driving to turn on the ignition, shift into gear, accelerate, steer, and break. You can test it on familiar roads. And you have a limited time period to assess performance.
That’s not the case for a sandbox.
Not an Accurate Representation of Your Experience
The truth is that a software sandbox is not an accurate representation of your experience. It’s like getting behind the wheel with no driver education, no driver’s license, and no idea how to adjust the seat or mirrors. No matter how nice the car is, you’re in for a rough ride.
- You’re not trained to use it. Did you ever go through a core conversion? If so, you know that training is frontloaded into the first third of the process because it’s essential to success. The same is true for most other software solutions.
Users need more than a 60-minute demo if they really want the knowledge and training to dig into the functionality of a product. When a user goes into a system untrained and can’t figure out how to do or find something, they assume it’s a problem with the product, not a lack of training.
- Your data isn’t in it. Sandboxes come with generic data. This data may not align with your FI’s data and approach. You don’t get to see how the solution would work with your customized data and processes.
- You’re only testing the software component. Many vendor solutions offer a combination of solutions and services, including subject matter experts (SMEs) and customer support. When you’re in the sandbox, you’re not seeing how these two elements work together, giving you a limited view of functionality.
- You don’t have time to really play with it. You’re busy. You don’t have a ton of time to play around with generic data in a software program you may or may not use—which is why you’ll get the sandbox and keep putting off digging into it. Maybe you’ll ask for an extension or three. By the time you actually begin to kick the tires, you’ve forgotten what you learned during the demo and either have to repeat it or go it alone. Either way, it wastes more of your valuable time.
Software sandboxes don’t give you a true representation of the experience you’d have if you purchased, trained on, and implemented a solution—but that doesn’t mean there isn’t anything you can do to get a better picture for how a product will perform.
Instead of asking for a sandbox, invest your time in:
- Due diligence. Find out how many clients a third-party vendor has, how long it’s been in business, its reputation, and other questions central to vendor management due diligence.
- Understanding your specific needs. Spend time assessing your concerns and expectations before vendor meetings so you can make the most of your time and have your top priorities addressed. Quantity isn’t quality. Focus attention where it’s most needed.
- Asking for a guided tour. Instead of wandering through the product to try and figure how it can meet your needs, schedule a guided tour to address those concerns. You can ask to go through key functionalities, and then ask your guide to let you take over and try for yourself. You can click or point, asking questions along the way.
A guided tour will help you find out what you want to know quickly and with less hassle. Instead of a test drive, it’s a combination of valet parking and driver’s ed.
- Asking for references. If you want to find out how a solution really works, talk to financial institutions like yours that are already using it. You’ll get their unvarnished opinion of what they like, what they don’t like, and if they’d recommend buying it.
Don’t get caught up in a sandbox that turns into a sand trap. Avoid these common software sandbox pitfalls.