Out of the box (OOTB or just OOB) is a small phrase with a big impact. It can help you decide why one software product is better than another (“We chose this application because it has more order management features out of the box.”); it lines the pockets of sales reps the world over (“Because we offer more features out of the box, you’ll be live in weeks, not months!“); and it causes quite a few headaches for software integrators like us (“How the hell can you charge me 5 days work for this feature? We saw this in the demo and were told it was out of the box!“)
OOB. So what’s it really mean? Is OOB just an elaborate fabrication of software vendors supported by a sexy demo in order for them to sell you their product? Or is that feature really out of the box and is your integration partner just squeezing you for a few more dollars?
The truth is generally, neither. Whilst it’s possible that your sales guy is embellishing a little too hard (a case of ‘BS’ OOB perhaps?), usually you just need to dig deeper to understand the context in which the OOB statement is made; and to have an appreciation of what you or someone else in your company will want to do, or have to do to make the OOB feature work exactly the way you need it to work.
A good example is a shipment confirmation email. Your customer places an order, you ship the goods, and the customer receives an email confirming the shipment has left your warehouse. Simple, right? So how can we charge you for 3 days work to implement the OOB shipment confirmation email?
Firstly, we need to work with you align the design of the email with your business’ fulfilment process, because it’s highly likely the OOB version won’t fit as is. For example, the OOB version probably assumes you’ve shipped the whole order to the customer, but what if you only shipped PART of the order – do you need to show the unshipped products as well as the shipped ones? Do you have gift vouchers or can customers pay with points? Do you ship internationally? Does your marketing department want to include promotions or personalised messages somewhere in the layout?
Whatever you decide you need, we’ll document the decisions, create the acceptance criteria and test cases. And we’ll need updated HTML & CSS to support the designs. (Let’s say a day’s work to sort all this out)
The next step is for us to load the customised template into the ecommerce platform, and map the fields. Then we’ll import test content, unit test and fix any bugs, remembering that we are co-ordinating with payment gateways and warehouse systems, and that such integrations are usually far from simple to test. (1-2 days)
Then we’ll hand things over to you for your acceptance, and everything will look fine, until more end-to-end testing reveals that some of the content in your ERP isn’t quite fitting with the design assumptions that you’ve made. So we’ll need to tweak formatting, retest, debug and deploy again (1 day)
Did I say 3 days? It could easily stretch out to 4 or 5.
The above is one example of an OOB feature that’s more accurately called a core capability and that requires a lot of customisation to make work for you. Such features are often just a checkbox on an RFP, and they sound so easy we don’t think about them, but they are really just building blocks. Features such as ‘email confirmations’, ‘split orders’, ‘back-orders’ vary so much in how you can apply them to your business, it’s simply not feasible for a software vendor to provide something that will meet the needs of every customer. You can expect that you will still need to do a significant amount of design, development, integration, testing and bug fix to make use of them.
Another classic OOB assumption is that the out-of-the-box website templates will meet your needs. “You get a website 80% out of the box. Just plug in your logo, images, products, and you’re good to go“. Such a statement not only conveniently ignores that you might want to actually integrate a payment gateway, address validation, CRM, a shipping system and so forth, it also assumes that your marketing department is going to be happy to allow you to dictate how this major customer-facing application looks and behaves.
Taking this a step further, if you aren’t careful, your creative team may design you a website that doesn’t actually leverage your platform’s OOB capabilities at all, or worse-still, completely ignores some core product capabilities like the OOB navigation frameworks. This is actually more common than you might think because the creative process typically happens independently of the functional design. It’s really important that your creative and operational teams work closely with your platform experts during the design process if you want to avoid this. (And don’t think they won’t resent you trying to inhibit their “creativity”!!).
Then there are OOB features that may, in fact, work as promised, but when you dive under the covers, they don’t quite meet all your use-cases. ‘Sure, Multi-buy promotions are OOB‘. Great. Check. ‘Oh, hang on, you wanted multi-buy with percentage discount? Sorry, the OOB version of multi-buy only does a $ discount, not percentage. ‘ In order to not get caught out by this, you need to work hard up-front to document specific examples of your business needs, and to deep dive with your vendor or integration partner.
Of course, there actually are OOB features that are useful, out of the box, without customisation. For example, the content management tool may include OOB features like “drag and drop”, “bulk edit”, “import from CSV” and “search synonym management”. Typically such features are part of the user and administrative toolsets.
So how much weight should the out of the box statement carry? Whilst the above might paint a negative picture, it’s important to appreciate that the number of OOB features remains a highly useful measure of product capability. Regardless of the amount of customisation and integration required, OOB still means less coding, faster deployments, integration consistency and more deployment options. What it doesn’t mean though, is that you don’t need to carefully design, customise and integrate such features to suit your needs.
In order to truly appreciate more what OOB means to your business, we recommend the following:
- Ask more questions of your vendor (qualify what OOB means each time you hear it)
- As not all vendors have actually implemented themselves, you should deep dive with an integration partner that REALLY knows the product and can give you a school-of-hard-knocks perspective.
- Try to stick as much as you can to the OOB templates provided by the vendor and have your platform experts / implementation partner work closely with your creative team during design
- Get your internal stakeholders on-board early, and clearly document detailed requirements and a full set of examples/use cases