“Don’t let the back end run the front end”

I’ve heard that saying many times over the years, and there’s some wisdom to it. You want to make the best possible offer with the customer in mind, not the offer that makes your systems people happy.

But … the more I get involved in the back end — either from the IT side or the fulfillment side — I realize it’s not so simple, and that ignoring the back end as if that’s going to help you on the front end doesn’t work.

Systems aren’t creative or flexible. They’re designed to do certain things. As a programmer colleague told me, systems (computers) are very good at doing one thing a million times. Marketers often want to do a million things one time.

Another way to look at this is something I call the Frank Rule (although it’s not really a rule): “We’re going to do all this set up and create all these special rules and exceptions and churn and we’re going to get one order.”

When you add exceptions and special rules for weird circumstances, two things are likely to happen: (1) you create lots of manual work to force the system to do your bidding, and/or (2) your system becomes a mind-boggling mess that nobody wants to touch.

For example, let’s take one very narrow slice of the publishing pie. Renewals.

It starts off very simple. For every order on file, we want to send out renewal notices 3 months before expire, then again at 2 months, 1 month, at expire, and 1 month past expire. Easy peasy.

Until marketing says they want to make an early bird offer for the first effort, or they want to attach the renewal notice to the issue, or they want to add a free issue, or ….

There’s no end to the creative sorts of offers that can be made, and that’s just for one product at one company. When you start to mix in different kinds of products with different terms, different prices, different special offers, club discounts, etc., it can get very complex.

The system needs to try to accommodate all these variations, but it also needs to be stable. If the programmers change the system to accommodate Company A’s quirky renewal series, they don’t want to mess up Company B’s series in the process. After a while, the system starts to look like a very complicated house of cards, and everybody’s afraid to do anything with it.

So how do you work in that sort of environment?

Clearly you start with the offer. What do you want to do, irrespective of the system’s constraints? Then you see if the system accommodates that offer. In those cases where it doesn’t, you have a few choices. (Which don’t include pitching a fit and screaming “why can’t you just ___?”)

1. Do a workaround. E.g., the system can’t take an order without a proper postal address, but you want people to be able to sign up with just their name and email address. So you supply a generic postal address with all these orders. (How does that happen?)

Unfortunately, that messes up your reports, which sort based on zip code, so somebody has to manually export the data and redo the reports.

You can do this sort of klugy thing, but you need to stop and ask if you’re going to spend more in manual workarounds than you’re going to make with your genius offer.

2. Use a different system. When system A doesn’t do exactly what you want, it’s tempting to use system B — just for this offer. But this often creates lots of other problems.

Will orders placed through system B go into the same customer service / account management areas on your website? Will customers be able to login with their regular credentials? Will these orders report properly to accounting? Will you have to build a new interface with your email system?

Is it all worth the churn?

3. Change your offer. Or, in other words, let the back end drive the front end.

It’s frustrating. Even maddening. But it’s often the right choice.

There are times when you can do a workaround or use a different system without making of mess of everything, but … not all that often.

Leave a Reply

Your email address will not be published. Required fields are marked *

sixteen − 2 =