Optimize Your Fulfillment: Unpack KIBO's Intelligent Order Routing

Transcript

In this demonstration, we will be covering KIBO’s order routing service.

After this walk through, you’ll have a better understanding of the logic that can be used in the routing engine, the breadth of extensibility that can be utilized, and how we’ve built this complex logic and extensibility into a UI that is very intuitive for business users.

Order routing is the business user interface that’s used to set the sourcing and routing logic.

You may also know this as order sourcing.

When we think about order routing, I want you to all think about it fundamentally as a rules based engine for the allocation of inventory.

Not the promise of inventory, not the availability to promise of inventory, but rather the allocation of inventory.

So at this stage in the process, we have an order that’s come in. We’ve already set the expectation when the customer order comes in. So one of the first things we need to do is allocate the inventory so that we can fulfill that promise that we made when the order was created by the customer.

Order routing is a service, and the order routing engine and the UI that we’re going to look at today is just a rules based engine that spits out a recommendation to the order management system on what to do next.

But it doesn’t actually take the action itself.

Rather, like I said before, it’s just a decision engine in that way. It’s a recommendation engine that’s based on some sort of rules that a business user creates.

Here are the if then statements. If it meets this criteria, where the criteria in this case is a scenario with or without filters, then we’re going to look at the middle column, which is what options do I want to look for as it relates to our fulfillment locations.

All of the different location types, the different locations themselves, and then how do I want to think about prioritizing these different locations.

Once I’ve got that figured out, if I can make a match, then what is my decision around a match or not a match and the action that results as part of that?

We cycle through all of this, and on the other end, we get allocated inventory.

So if we don’t actually meet the conditions in this first scenario, then we’re going to drop into the next one. So if you follow my cursor, we’ve got an order. We’re going to consider this first. If the answer is no, we don’t meet any of that criteria, then we jump down to the next scenario, and we bypass all of the logic here.

This decision point happening here without having to run through all the lines of codes of logic that’s sitting behind all of this makes it an extremely highly efficient and highly responsive engine.

Now as for the after action, order routing will decide based on split decisions within the after actions of whether or not there’s more than one location that’s going to fulfill this.

That’s what we’re going to come back with and recommend.

Coming into the order routing screen, you will see up at the top we have various sites or catalog structures and each of these have their own strategies for order routing.

As you can see here, we can have multiple strategies created at any given time. However, at any given point in time, we can only have one active active strategy.

In order to activate an inactive strategy, it’s as simple as selecting promote to active here.

Not only does having multiple strategies created allow us to plan or schedule for different events such as holiday peak or Black Friday, it also provides the ability to react in real time or proactively to an impactful event that we can’t control, such as weather.

So in this case, we can actually create a strategy that moves all fulfillment to a certain location based on impactful weather in the area. So now let’s go ahead and click into one of these strategies and show what it looks like.

The first thing that you will notice in the middle of the screen is we have two different fulfillment types. On the left hand side, we will have our direct ship fulfillment type. So in this case, the customer chooses to receive the product that will be directly shipped to them from either a store or a distribution center.

On the right hand side, we have the fulfillment type of transfer to store. So in this scenario, if the customer decides to pick it up in store, but the store does not have any inventory available at that store, how are we going to get that inventory to the store so that the customer can come and pick it up?

What you don’t see here is click and collect or BOPIS because in these use cases, the customer is either in the store or they choose which store to pick up their order from. So we do not actually have to consult the order routing engine to make that decision for us.

Over on the left hand side, you will see a few different options that we can choose from. I will speak about a few of them now and the others we will get to later on in this video. If I go ahead and select locations, you’ll see that it displays all of the different locations that exist within our network for possible matches for order fulfillment.

You’ll see in the middle portion of the screen the locations as well as some of the related information.

On the right hand side of the screen, you’ll see that whether this location is active or inactive as it relates to order routing.

If I select into the individual location, you will see here that I have the ability to activate or deactivate at the individual location level.

In addition, if I select the existing scenarios, it’ll show all of the different scenarios in which this individual location is associated to.

Coming back to the main locations page, I have the ability here to modify multiple locations at any given time.

If I select these different locations and come up here, you will see we have a few different options to choose from. We can remove all of these from a scenario, we can create a new scenario against these locations, we can activate or deactivate a scenario, all within a bulk or mass faction.

Now selecting filters, we will see that this brings up a large list of different filters that have been created on this routing strategy.

If you remember back from the slide, filters are essentially the if statements that make up the scenario of each routing strategy.

We can create as many filters as required.

Filters are really where the power, logic, and extensibility live within the system.

We can create a filter to handle those nonstandard use cases. We can use any location, product, order, customer, or inventory attribute to filter off of. This is where we really start to talk about the extensibility of the order routing engine.

It’s great to be able to set some standard order routing rules, but what we have found is, inevitably, customer a has a use case that nobody else has. Customer b has another use case that nobody else has, etcetera.

Rather than building a feature for each unique routing use case, we’ve opened it up so that we can configure it exactly how we need. We can use any custom attributes that we have created. For example, if we have a product attribute where the season is equal to spring because we have a product catalog, we can take that attribute and use it for routing and sourcing logic.

Again, we could set this up for a custom order location, product, inventory, and customer attributes.

For this use case, let’s create a filter based off of custom customer attribute, and let’s call this our gold loyalty segment.

Let’s say if the loyalty level is equal to gold, then attempt an assignment.

These custom attributes live natively within the platform, and all data models are fully extensible.

They’re configured here for a business user to go configure the rule set. Again, we don’t have to write code or develop anything to make this work. We configure it here as a business user and set this rule.

Moving on, if I go ahead and select custom data list, you will see we have a custom data list that has been created.

You can think of a data list as essentially a way to extend order routing in order to create different lists about various data within the platform.

For instance, if a scenario cannot fulfill certain product UPCs then a custom data list could be created containing those UPCs.

A filter could be applied to this scenario with the data list applied to the item UPC attribute so that these items would not be assigned to individual locations in that scenario.

Now if we come here and select custom datasets, we notice we have one created for labor rates. So what a dataset is is it provides the ability to define custom location specific data types that can be used in filters, such as to reject locations with a particular value, or this data can also be used as a sort option in scenarios to compare the various locations.

This could be hourly rates as we’re showing here in this use case. However, it could be staff levels or really any other attribute that can be applied to every location but still can vary in the value.

So now that we have gone over some of the different concepts and options, let’s actually go back to our strategy and talk through this a little more.

Once again, you will see here that we have a couple different options to set up our routing strategy for.

The way we should think about order routing is like a funnel. We’ve got our direct ship location groups listed here. The logic runs in the order that we have listed.

What this means is when an order comes into KIBO, we’re going to look at the order and see if there is a store that can fulfill this within a hundred miles of the customer first.

If not, is there a distribution center that can fulfill this whole order within three hundred miles of the customer?

If not, are there any stores within three hundred miles?

If not, down the list we go. This is just one example.

Some of our customers will choose by the cheapest shipping cost. We can also route based off of specific attributes, like stores that offer gift wrapping or special packaging.

If a gift wrap order comes in, we’ll need to look at the gift wrapping stores first, and then we can look elsewhere.

The point here being it’s very flexible for us to set up and configure for all sorts of different scenarios.

We’ve exposed all that functionality in a user interface, and we’ve made the interface very intuitive so that the capabilities can be configured, managed, tested, and deployed completely by the business users.

There is no dev required to set any of this up. We can still do it via API, however, because, again, all of our UIs are built on top of our APIs. Let’s say now we wanted to create a new group. Maybe we want to create a group where if a loyalty customer place as an order, all of their orders will be fulfilled from the top fulfilling stores and warehouses within our network.

If multiple locations have that inventory, how do we choose where to fulfill from?

If there’s a store that’s ten miles away and a store that’s a hundred miles away, which one gets that order? We can assign it based on distance, inventory velocity, carrier cost, or any other custom data that we want to use to route, whether it’s labor rate, location performance, or whatever.

Let’s use carrier cost. If two locations have the exact same shipping cost to ship this out to their customer, then we’ll break the tie based on distance.

We can limit the fulfillment for the locations in this group if we want to either by shipments, items, or dollars and factor that by hour, day, week, or month.

The second step here is where we select the actual locations we want to include in this group, and we can include as little or as many as we want.

Next, the third step in the process is setting up the filters.

We could layer on multiple filters if we wanted to. For an example, we could apply our gold loyalty segment filter and another one for orders over five thousand.

As many filters as we need to get the desired logic.

The fourth step is where we add in our after actions.

This will be what happens if we can’t fulfill the entire order in this group.

We can see that try next group is the default option and is usually used until an order gets through a list of groups initially.

But what do we want to do if something else happens where we get a partial or no match at all? If no group can fulfill the entire order, maybe we want to split it by line item and rerun through the logic.

Maybe we want to split it by quantity and rerun through the logic.

Maybe we just want to assign the entire order to our customer care because we want our customer care team to be able to make the decision here.

We can configure this kind of after action for each group we create.

Now that we’ve created a new group, we can move this up to the top if we want.

Now when a direct ship order comes in, if the customer’s loyalty level is gold on that order, we’re automatically going to look at the locations we added into this group. If inventory is not available, then we’ll look at the next set of locations.

If the loyalty level is not equal to gold, we’ll just go ahead, skip over this group, and run it through the subsequent groups.

The moment we set this rule into production, it’s going to run that through KIBO’s get candidate API.

If we want to call it from the storefront when we place an order, it will return all the information on where it’s going to be routed from and we’ll do it all in real time.

Then we can do whatever we want with that information on the storefront.

Again, this is just one example. There’s a wide array of products being sold and shipped, so there’s an immeasurable amount of use cases that could be generated.

What we typically do when working with our customers is we reverse engineer what they want to have happen. This is the result they want, the experience they expect, and from there, we can determine how we could configure that in our order routing engine and try to expand on our customer’s thought process.

The default thinking is to assign it to the location closest to the customer, which we can absolutely do. But there’s a lot of different flexibility here that we can use to leverage to save on operational cost and create a better customer experience for our customers.

This is very powerful business user tooling and the ability to set the sourcing and routing logic here, but also technological tools and endpoints enabling our users to complete the customer experience and set proper customer expectations.

Lastly, KIBO offers suggestion logs and debugs for our order routing logic. If we have a suggestion ID, order number, or external response ID, we can input it here and the logs will be shown with the exact path that the this order took in its order routing journey.

That concludes this video. I hope you found it very beneficial.

Thank you.