Dovetail Software – Some Assembly Required
Some Assembly Required
When you swing by Target to pick up a Lego Millennium Falcon, you probably don’t expect to open that box at home and find a fully-built Falcon waiting for you. Instead, you expect to see organized bags of pieces and instructions on putting your new space ride together. Frankly, if you did get one already put together, you’d probably want to take it apart and start over. And maybe you want your Falcon to be a little different. Maybe you want the new square radar dish instead of the classic round version. Maybe you want to add more thrusters, or more guns, or finally get the hyperdrive upgraded in your version. That’s the best thing about Lego. You can do whatever you want. And you can always take it apart and do something different later.
A good SaaS product is no different.
We give you the pieces and the instructions, but we also come home with you and help with assembly. Metaphorically speaking, of course. Our goal is to not only make sure that your Falcon is the Falcon of your dreams, but that you know how to take it apart and rebuild it later if you like. That requires some assembly, yes, but in the end you get a ship that isn’t just off the shelf. It’s yours, and is built the way you want it.
One of the great things about a SaaS system like ours is that it is designed to be bent and twisted to meet the needs of our clients. You’ll hear us talk about zero required customization and a system that can meet a wide variety of needs right out of the box. And while that’s true, it does mean there are some decisions that need to be made and some configuration work to be done to set up your system for a successful launch. While certainly not comprehensive, here are a few of the common items we go through in the process of implementing a new installation.
PROCESSES
The Alpha and the Omega of any good technology deployment, the processes upon which your system will be built are critical to getting it set up and adopted quickly. In fact, this is usually my opening request of any new client. Can you send me or show me your process maps?
Admittedly, I may be a little biased, having spent years focused on process design and deployment. But I am a firm believer that technology should support, not define, how you work. I am also a believer that “best practices” are rarely applicable as they are stated, and the best path to excellence is to define your current state as honestly as possible, then look for ways to improve. Best practices might be helpful during that stage, but they are certainly not a place to start.
COMMUNICATIONS
One of the benefits you can gain from our system is a bump in productivity. IF you’ve worked with large scale support teams, you’ll know that the higher the volume of cases, the smaller the improvement needs to be to have a significant bottom-line impact. I may only save a nickel per transaction, but if I’m hitting 10,000 transactions a day, those nickels add up quickly, and they shouldn’t be ignored.
One of the easiest methods of collecting those nickels (or, if you are a really lucky, maybe some foldin’ money) is to pre-script outbound messages. There are a bounty of repeated messages that can be set up, such as those for onboarding, responding to vacation requests, approvals (either requesting or granting), or termination notices. Getting them written and stored in the system for quick retrieval can make a big difference in the aggregate.
RULES
Probably the most misunderstood feature is the Rules Engine. We often hear requests to build “workflow,” but after some probing find that the term itself is a bit ambiguous. What qualifies as workflow for some would be approval chains for others, or simply a defined routing or escalation path. They are all different, but often called the same thing. Rather than build a prescriptive system based on what we would call workflow, we’ve instead created a Rules Engine that allows our clients to do it for themselves, and change it as needed. Our rules are often as simple as “When this happens, do that.” Of course, with the amount of configuration options available, it can be more complex, such as “When one of these six things happen, assuming these five things are true and these two things are not true, do these three things, but not all at once, and wait an hour between the second and third, and only do that last thing if something else doesn’t happen first.” Yes, sounds confusing, and it can be. That’s why we work our way up from simple rules to complex rules. But our mantra is if you can describe it to the system, the system can probably do it.
Your Choice!
There are a lot of areas where you can get your pre-work and documentation ready before starting an implementation, and it will make the process smoother, faster and deliver a more complete setup. Without them, you’ll get something that looks a lot more like the picture of Millennium Falcon you see on the Lego box. And while there’s nothing wrong with that, we just think you deserve to make a few design choices along the way!
