Updated July 1, 2022.

In SAP e-commerce, requested delivery date can make or break you. Your B2B e-commerce platform is a cross-functional application. An SAP inventory management decision impacts different people in different ways all across the organization. You may not see the impact of your decisions on other departments until those decisions go into production. Suddenly those choices are live, working in real time, making life easier (or harder) for people at your company.

There’s no greater example of this principle than managing RDD (requested delivery date) in B2B e-commerce. We’ll illustrate this point with a story from one of our clients, then talk about the application and what it means for your business management.

The Problem: Everyone wants 100% on-time delivery

There’s a metric that every organization has to live by: the percentage of orders that have been fulfilled on time (and in-full). The customer has entered an RDD (requested delivery date). On the day the customer receives the goods/services, you generate an actual receipt date. You compare the two dates and get a yes/no answer on whether the order was fulfilled on time.

Everyone in your organization wants 100% on time delivery. If you can stare at that stat on your screen, you feel good about your business and your customer satisfaction.

But what does 100% on-time delivery mean? It’s a metric like any other, which means people can play games with it. How are you actually calculating it? The customer doesn’t care when the product leaves the factory. They care when it gets to their doorstep. Now you have to take the shipping process into account, with all its potential delays. You have to bake all of that data into your on-time delivery estimate.

Why it matters: Real people use B2B e-commerce!

Let’s not lose sight of this fact: amongst all the statistics, acronyms, metrics, and technologies, real people are coming to your e-commerce store with real needs. Your customers and your employees are the ultimate reality behind e-commerce—and each one of them has different concerns and different needs.

Can e-commerce satisfy all of them? Absolutely. The key is to understand the unintended consequences that decisions can have on real people.

Our client’s requested delivery date story is a great example of this.

They didn’t want to disappoint their customers, so they set an EDD (estimated delivery date) further out. The unintended consequence was, not only could the client not disappoint their customers, but the new EDD policy prevented the client from delighting their customers. Ouch!  

How requested delivery date works in SAP

The moment the customer puts in a requested delivery date, SAP calculates a date when the product could hypothetically be delivered. This calculation is quite complex, and it’s based on numerous factors—whether the product is in inventory, how long it takes to build or by the product if it isn’t in inventory, whether the raw materials to build the product are available right now, and much more. After working through the calculations, SAP schedules a date.

RDD in SAP e-commerce

If you’re calculating requested delivery date in SAP, it’s actually fairly simple to take that data from SAP and display it in your SAP-integrated e-commerce store. Our client did just that. They decided they wanted to allow the e-commerce customer to choose an RDD. They would manage everything on the back end to fulfill that RDD.

As we’ll see, though, getting the data into e-commerce was only the beginning of the journey. Our client had to account for how this level of customer choice would affect their business processes, and that was difficult to predict.

Requested delivery date hits a snag

After our client implemented RDD selection on their e-commerce site, they realized they weren’t hitting the RDDs. It was difficult to fulfill the orders in the time specified. The stats were looking bad—and no one likes looking at metrics that come in under the bar.

We advised our client that they had 2 options:

1. Ship quicker to meet RDD. Figure out more efficient business processes to achieve that.
2. Don’t let the customer enter a date that you can’t deliver. That means switching to an EDD (estimated delivery date) model.

Our client chose the second option. They switched to EDD (estimated delivery date).

How EDD works in SAP e-commerce

Here’s how EDD works in an SAP-integrated e-commerce store. The customer logs in. For a line item, SAP provides an EDD, which has all relevant delays baked into it (i.e. inventory status, production lead time, shipping time, or a simple rule such as adding 5 days based upon the factory calendar). The website displays the earliest date the customer can expect to receive the product. The customer is allowed to specify an RDD, but it can’t be earlier than that earliest date (the EDD).

The switch to EDD: Real-world experience

Our client monkeyed with the stats on order fulfillment, then put the EDD solution into production. But a new problem popped up. Remember, the only thing constant in B2B e-commerce is change. If things changed at the factory, which they did, suddenly there was more inventory than was available on the day that the client ordered. Now, due to the status of physical inventory, the order could be fulfilled immediately–but SAP won’t allow it to be fulfilled until the EDD!

Now our client was stuck with surplus inventory (read: lost revenue and increased cost).  

That was an unintended consequence of changing RDD to EDD. Our client ended up with too much inventory because they could’ve delivered faster than the EDD.

The solution: back to RDD

Our client’s warehouse management team requested a change back to RDD. They decided it was better to have real data and be forced to deliver on time, rather than to slow things down with an EDD calculation that may or may not be accurate in the future.

RDD in the world of Amazon

Obviously, the RDD/EDD decision isn’t “one size fits all.” Every business is different—but there are options. For example, some manufacturers use RDD, but they don’t allow the RDD to be any sooner than 2 days from now. By default, SAP looks at today’s date, adds two days, that’s your earliest RDD.

But Amazon can give you product almost instantly.

That’s the competitive pressure here, and it’s growing, now that Amazon is offering Business Prime. The service is $499 a year for B2B companies with up to 10 users. (The pricing scales way up from there.) This flabbergasts manufacturers. How are they supposed to compete? Now, there are all sorts of asterisks, and they have to fulfill it.

The call to manufacturers: Shift your thinking

The point is, manufacturers need to get out of their own heads, out of their own metrics, out of their own old ways of thinking and doing business—because once you get to e-commerce, the customer is in control. Whether you like it or not, the customer is experiencing Amazon standards at home, at night, and bringing those expectations to work during the day.

That’s the pressure. You can resist it as long as you want, but it’s real.

This change will look different in different organizations. Every organization has competing internal metrics that aren’t about the customer, but about the department. Every department likes locally-optimized metrics, rather than globally-optimized.

This is a mistake. The only metric that matters is one that measures customer satisfaction. And it starts with a customer-first culture, not a company-first culture.

RDD illustrates this perfectly. RDD functionality on an e-commerce website website isn’t the manufacturer communicating to the customer, it’s the customer communicating to the manufacturer.

How we support manufacturers in transition

No one can make this shift overnight. It’s an iterative process. In this case, our client through several iterations of learning. That was a little frustrating for us, the sense of shifting requirements and uncertainty on what the end goal would be. But we realized that our role was simply to support our client as they figured out the best processes for their business. Now, in hindsight, we can say that the client took the best approach they possibly could—trying one thing, finding it didn’t work, modifying the solution, and modifying it again.

In fact, the client showed us a new expression of one of our Core Values—“Pursue perfection pragmatically.” The client iterated their approach to RDD/EDD, searching for perfection, and ultimately settling with the best option that was available.