What inspired us to build the In-a-Box solution?

The inspiration for In-a-Box comes from two things we’ve seen over the past few years of implementing Dynamics CRM.

MS Dynamics CRM, now part of Dynamics 365, is a complex, enterprise product which is feature rich and extendable. In practical terms, it is a massive toolset of options available to the user. This means that it often requires extensive professional services projects to configure/customise the solution to the needs of a particular instance. While these projects are interesting, they’re also expensive and create a significant barrier to entry to many smaller businesses wanting to benefit from the power of the platform.

And all the while, the world is changing. More and more enterprise class services are being sold on a monthly subscription basis (per user, per month) at rates that are very affordable for small and medium businesses. To Microsoft’s credit, the “new Microsoft” has recognised this and is turning many of its traditional boxed software businesses to be cloud first (Office 365, Dynamics 365, Azure services, etc.). Dynamics 365 can be had for well under £100/user/month, a small price to pay for the power it provides.

But there remains a gap between this massive hurdle getting onto the platform relative to the monthly cost of using the platform. Small and medium businesses just don’t have tens of thousands of pounds to hand to spend on software projects. The In-a-Box products were conceived to bridge that gap. We’ve consolidated our experience across hundreds of implementations, looking at the things most businesses have asked for, and built this into a packaged solution.

The design focus has been driven by two principles:

  • Simplification of the solution: pare down the forms to use the most commonly used data fields, provide a handful of well-designed business processes, deactivate views to hide complexity, etc.
  • Don’t break the underlying data model: part of the attractiveness of Dynamics 365 is that it provides a scalable path for businesses who either grow or have new business requirements (Customer Service, Project Service, xRM, etc.). By staying true to the data model, we can ensure our clients are not compromised in any way by decisions taken in respect of using an In-a-Box solution rather than a bespoke implementation.

The downside is plain to see. By using an In-a-Box solution, you’re limited to the design decisions made in building the solution. It’s not really different to buying a physical product at a retailer. There are probably a few options you could exercise, but the core product is the one you bought. The software may only meet 85% of your requirements rather than the 100% that a bespoke implementation may achieve. With a handful of consulting days, you might close that gap to 90% and still stay in the realms of a reasonable cost. (Or, better, use the system for 3 months, and then re-assess whether perceived needs are real needs!)

I guess it boils down to a simple question: do you want stay on spreadsheets (as many of the target customer base are likely to be using) or, for a reasonable cost, cover 85 or 90% of your requirement? Because the 100% requirement is just not realistic for small and medium businesses.

 

Recursyv Sales In-a-Box is now commercially available. If you’re interested in discussing these ideas further or a demo, please be in touch.

Note: We’re aware that Dynamics 365 Business Edition is a similar application of this mindset. In another post, we’ll share some of our considerations in respect of furthering developing of this product versus waiting for Business Edition. 

We’re going undercover

In response to suggesting we’re “going undercover to focus on product build”, a former colleague and dedicated jpg prankster has helpfully updated our profile pics.

 

Groucho JonGinger Groucho David

 

Sadly, it’s probably an improvement.

Designing for a happy birthday

In celebration of our first “official” day designing and developing software for Recursyv, we turn our attention to the birthday controls within Dynamics CRM. Getting to know customers and being responsive to them on a personal level is one of the drivers of implementing a CRM system. In this light, it’s frustrating that the storing and use of birth dates is so poorly handled.

Let me illustrate with the birthday selector on the contact form.

2016-11-17-birthday-selector-with-border

It’s a standard date control. You’d think there’d be no problem there, but in practice it means that either you need to know the contact’s birth year or your data is inaccurate. One is unlikely, the other is inelegant. Neither make for great design. In practice, the pragmatic approach is just to ignore birth year in the data set, but it seems that in a mature software system, it shouldn’t be necessary to use workarounds for such basic features.

Our design ambition for the In-a-Box product set is that it should be intuitive and easy-to-use. Inelegant workarounds don’t fit into this mindset. Consequently, our current thinking for the In-a-Box product set is to create custom fields for birthday (day of the month, i.e. 1 – 31) and birth month. This will at least enforce that data held on system is robust (i.e. accurate). It will require some changes to views but that’s straightforward enough. In practice, the data should be used to drive dynamic marketing lists and that is easily achievable with data structured like this.