Mi360 is a relational database system. This means modeling the real world as closely as possible and remaining adaptable for changes to meet future needs. We get a lot of value by creating reports from Mi360’s data, reports that yield usable conclusions. These reports give us the answers to complex marketing problems presented in the language of marketing experts. So the benefit of having your marketing data in a relational database system is the cornucopia of conclusions that it yields.
The problem with relational database systems that have many inter dependencies is that they tend to be cumbersome and unusable. The situations that need to be recorded are events and observations that need to be categorized. To do that the category has to exist ahead of time. And if that category was a subcategory or child of another level of data then the primary objects need to be recorded first before the event can be recorded as belonging to the appropriate category. So for most relational database systems you’ve got to set up all of your parent records first, entering them in their management windows, and then recording live events in their own window. This opening and closing of windows is distracting, time consuming, and cumbersome.
Mi360 had, in its first iteration, many “add on the fly” features that made it highly usable for one purpose: recording ad buy properties while you’re on the phone with the ad vendor. This meant that if a new tactic or publication needed to be defined, because it wasn’t in the pick-list, the tactic or publication could be added on the fly without closing the order entry window. Everyone loved it and it made recording new ad buys very fast.
Then when we migrated to the new Mi360 interface we initially migrated the basic functionality but didn’t migrate the usability features. This mean opening and closing windows in a clunky way that felt downright wrong because we had all become spoiled by the ease of use