Howdy,

Three questions for you to ponder:

• Why does multichannel software have to cost so much?
• Why do you get oversells?
• Why can’t that developer just add in that one extra box that you need?

That’s the questions I’m going to be exploring in this article, feel free to jump in and add your 2p worth in the comments at the bottom.

If you have any interest on what actually happens in the background to multichannel software, the software that manages your business across multiple marketplaces like eBay, Amazon or your own website, say Magento, you’ll want to pull your chair closer and grab a cuppa.

 

Before we start, let’s simplify the process down to it’s simplest of form.

The process to create a new product listing onto a marketplace, collect the order and then process it, you as a seller have to go through several key stages, these are:

1. Add a product to a database
2. List it onto eBay (or insert another marketplace here)
3. Collect the order
4. Despatch the order
5. Update the marketplace

That’s pretty much the entire process in 5 steps, create, list, collect, process, update.

And that’s where the simplicity ends.

If we think about step 1 for a moment “Add a product to a database”, this product could be anything, from a microphone to keyboard, a painting to a tent, there will be common attributes about each product, these are:

• Title
• Description
• One or more images
• Categorisation
• Price
• Condition
• Cost price
• Stock quantity

As you can see this will get deep very quickly, in fact it is, let’s pick on the products description for a few moments.

A products description could just be a block of text, but more likely it’s going to be broken out into many parts.

For example, let’s pick on a pair of shoes, picking on the bare minimum of requirements for listing a pair of shoes onto eBay, you’ll need to set a Shoe Size and the product Brand.

So that’s now 3 fields just for one product!

No seller in their right minds would just use the bare minimum and looking at the eBay Sell Your Item form for the boots category on eBay, it’s suggesting 10 product attributes  to add and 3 additional fields as secondary attributes and you could add in your own custom attributes  as well if you wanted to.

And we’ve not even considered that the business probably wants to separate their data out, so that they have say 5 key bullet points that they can use on Amazon and on their website, let alone another sales channel too and the main product description.

If we now consider the data requirements that are needed here, we’ve just sprung from 8 or so fields to way over 20. But also to use any software easily, then an interface would need to be built so that it’s easy for a business owner like you to be able to actually enter this information in.

We’re dealing with “expandable” and “unlimited” data, so while in boots category there maybe Shoe Size, Brand, Style etc… if we pick a completely unrelated category say tent’s for example, I’m now looking at a page where we have Type of Tent, Berth, Style, Sleeping Areas, Brand, Season, Model, MPN and the ability to add in extra options too.

There have been several different ways to invent this, there has been the just give the seller 20 fields and let them sort them out and match them up manually, there has been custom fields route where you define what the input boxes could look like and mix in a few different input types, such as an input box, a drop down box or a checkbox.

Oh and as I’m assuming that you maybe a larger business, you would probably want to set these fields up manually first and then use an import/export system to create, update and append information about your products.

To get to that stage a framework would need to be built that can handle that kind of data input, allow it to be searched upon (which is no mean feat over lots of fields of data) and an import/export system as well.

So have we just gone from a simple product description to a squllion fields? For which more than half were dictated by a marketplace to create?

I think so and this is just one of the challenges any inventory management system needs to cope with.

So let’s assume that this was written from scratch, this wouldn’t happen over night, it would take months, if not years to get right.

Again keeping this as simple as possible, let’s pretend we have just have a plain old pen (unchewed) as a product and we have 10 of these in stock, sat our shelf.

So get that product onto the marketplace, an integration would have needed to be built that allows you to actually send the product “up” so that it can be made for sale (we’ll come back to this later), but let’s assume the 10 pens are on the say eBay. Fantastic!

A customer buys one of these pens, so we have an order for a pen and we also have the customers details, their payment details, and the selected shipping method.

Again we’re assuming that an integration has been made to the marketplace, eBay in this case and also PayPal too to collect the payment (which isn’t a small task for even a seasoned developer).

But hey we’ve sold one, happy days.

When we’re dealing with just one marketplace, then stock control is pretty simple, we have 10 in stock, 1 sold, so we now have 9 available. Or you would have thought so.

What happens if that sale was an auction, the customer has not paid yet, so that 1 pen we just sold is now sat in a holding queue?

That then means you need to track your actual stock quantity and the held quantity and probably another integration to eBay (using eBay in this example as it has a lot of API’s) to handle disputes.

Let’s ignore that for now, we sold one, ace!

What’s the point of software if it’s only just going to do one sales channel?

We like our multiple sales channels as that means we can sell the same 10 pens across all the available sales channels, reach more potential buyers and basically sell more stuff.

Chucking in Amazon into the mix now, we had 10 pens listed on eBay and we had 10 pens listed on Amazon. And we sold one on eBay.

That now means that we need to let Amazon know that we only have 9 left.

Amazon uses a reports system for their integration, which basically means you send them a file that contains your stock levels, they sit on it for a while (5-15mins normally), don’t actually tell you that it went ok, only if something bad happened (and even then, they pass back a message that basically says “Huh?”), you have to assume that and with both of us crossing our fingers that it was received and processed.

Easy-peasy, we sold an item, eBay was already at 9, no need to update them, Amazon, we lobbed them a file, they didn’t go “huh?” at us about it and we’re all down to 9 now.

While all this was going on, we just took an order from our website.

Let’s say it’s a Magento website (I like Magento websites so we’re having a Magento website) and through another integration to Magento, the order has been collected and we now have 7 pens in stock, because the customer just bought two pens.

So our multichannel software has to kick in again and this time, tell eBay that we now have 7 (which is pretty quick via their API and it tells what was wrong, unlike Mr Huh? have the file back, there was an error “somewhere” in it), we tell Amazon that we also have 7, they don’t go “Huh?” at us and we’re all good.

Timmy on the phone takes an order for the last 7 pens (a real big spender that one), he enters the order manually in and assigns the last 7 pens to Mr Big Spender.

Oh pants, we need to let eBay know we have 0 left, great that will end the listing on eBay, take it off Amazon too and the Magento website.

But when we end it on eBay, we need to remember that we ended it and what the item number was, so that when we more of these super fast moving pens in again, when we list them again, we want to reference the previous eBay Item Number, so that what little best match ranking is carried over to the next listing.

Oh and we send a file to Amazon which may go “Huh?” or give us the silent treatment and we also send an update to Magento to take the item off the site and change the stock status to “Out of Stock”.

To recap, we’ve just had multiple integrations to different marketplaces:

• One that we need to remember what we did on it for next time (eBay)
• One marketplaces that gives us the silent treatment (Amazon)
• A Magento website
• And Timmy who took a phone order for Mr Big Spender

Now let’s times that by the other 999 products we had in our inventory system (or insert however many you have right now), is it any wonder that oversells happen from time to time?

Oversells, they suck nuts, but it’s amazing we don’t see more of them every single day.

It’s one of the side effects of the be-everywhere strategy that we see with multi-channel or “omni-channel” catch phrases being bounded around. If you sell on more than one marketplace or even on the same marketplace more than once, you’re bound to have an oversell sooner or later.

And the thing is, the software in the background has just been working it’s little leggies off try to do all the above as fast as it can, so that it’s users (that’s you) don’t phone up their account managers and give them an ear bending about DSR’s, Amazon Scores or some lerry-nut-job whose order couldn’t be fulfilled.

So if you were building multichannel software, then you’d need to add in the ability to track changes to products and update the outside world with those changes.

If we think about what our multi-channel software does on a daily basis, it’s no small feat.

Tens of thousands of hours would have gone into making it work right for near-as-damit 99.9% of the time. But because it is a separate system from the marketplaces that it’s interacting with, in many ways it’s piggy-in-the-middle.

This is just like the school playground game, but this time, the ball is the stock levels, orders and updates and the software is the one chasing the marketplaces around rather than the other school kids.

Let’s now say that you have one product, but you have 2 in stock and two marketplaces, eBay and Amazon

The challenge that we have when dealing with marketplaces are:

• Constantly updating API’s
• Constantly changing products (stock, descriptions etc…)
• No control over the the interfaces uptime
• And hopefully a consistent stream of orders and their updates as well

Note: API = “Application Programming Interface”.
It’s the Nerd term for how you can connect to a 3rd party system using a set of calls or instructions to add, edit or remove things. Typically the 3rd party such as eBay provide these and document them accordingly (pages and pages and pages of it)

The multichannel software needs to sit in the middle and work out what is happening with the marketplaces, what needs updating, what doesn’t and doesn’t just deal with one interface to speak with the marketplace, probably several.

Piggy in the middle is the best analogy for all this.

If it was for just one business, things would probably run quite smoothly, however the off-the-shelf providers (insert any name here, eSellerPro, ChannelAdvisor, Linnworks, StoreFeeder, SellerExpress and so on….) want to scale their multichannel software to more businesses, it’s how they make money, either through a monthly fee or a percentage of sale model.

And scaling up chaos is crazy (crazy good fun though!)

The one dynamic we’ve not covered to yet is the business itself that is using the software.

The software doesn’t just run by itself, there is oodles of human interaction to it as well, this could be a member of staff adding in new products, updating images, importing a stock update file or processing orders.

And not just one member of staff, probably lots!

If you thought that being piggy in the middle to the marketplaces, with their quirky interfaces or creating an inventory management system that can cope with extendible data that could come in any shape or form was tough, let’s account for the users (that’s you) that are working with the software everyday.

A typical day in any business will involve the following tasks:

• Creating new products
• Updating existing products
• Adding more stock
• Processing orders

You’ll note that I’m missing out luxuries like reporting & customer services, that’s a whole different kettle of fish.

Up until now we’ve only really covered the first 3 of these, we’ll get on to the processing orders task in a minute.

The thing is that while most businesses complete the same tasks, they don’t all go about them the same way.

One business may prefer to work heavily in excel spreadsheets, another with just the interface of the software, so not only does the front end of the software that the staff actually use need to be slick and easy to use.

This is the layer sat on top of the database that is being used in the background to store all the products and keep track of changes and the database is being hammered to try and keep the marketplaces in touch with the latest changes as well.

A topic which we only just touched a few moments ago, order processing, So we’ve managed to collect orders from different marketplaces through their different interfaces, now what?

Those orders need to be processed, this  involves some form of document being created, normally lots if we include emails as documents (such as order received, order despatched etc…).

Those need to be templated somehow and spat out either on demand by a member of staff pressing a button to print out an invoice or via some rules in the background, that send them out automatically.

So let’s say that’s happened and oh, we’ve brought in the payment for the order and matched that up to the right order (a feat in itself I hasten to add as they don’t always match up exactly, for example what happens if the customer paid too much or too little?).

Anyway, we have the order printed out in front of us, that order hits the real world, is picked and packed. But we’re missing something, that something is the courier label.

If we’re just dealing with Royal Mail, then we could have just printed out the PPI logo on the invoice. However a courier, well that’s another kettle of fish.

Unlike the USA where it’s pretty clear cut who the main providers are for actually sending orders (USPS, FedEx, UPS and DHL) with inexpensive integration tools like ShipStation or ShipWorks which costs peanuts, in the UK it’s a friggin mess.

Each courier has their own API and they all work differently, there is only one main software tool that has licked this and that’s Metapack. Metapack uses a SaaS model (software as a service) so that it’s pay-per-use and costs upwards of 12p per label. This is either a complete bargain or a massive expense, it depends how you look at it.

Many of the current software providers (in the UK) looked at it as an expense and built their own integrations into the couriers directly, thus adding another layer of complexity to the software that they built (and bloating it out even further).

Business Rules for Order Processing

One  area we’re missing here is that just because the customer selected Royal Mail 2nd Class, that doesn’t actually mean that it’s how the order is going to be sent. There are business rules that most likely need to be processed on top of the order to work out which method the order should be shipped.

If we think back to the example of the pens earlier, they are really light and have no real size to them, a letter would do. However what happens if the customer also bought some other office supplies at the same time and the weight hit 1.2Kg and the order value hit £35.

Suddenly the method that the customer chose and paid for doesn’t become cost effective, so instead a business rule may be that such an order because it has gone over 1.2Kg and went over £30, to send it via a courier instead.

But what happens if that customer was in the top of Scotland and our normal courier would charge us a surcharge, then a secondary rule would need to be put into place to switch the order so say Royal Mail tracked. It might not be as quick, but surely saves the £12 surcharge.

So any software that deals with orders and the despatch process needs to account for business rules that need to be applied to orders and this is where something like the 12p to Metapack becomes more attractive because they have this level of rules ability built in. Different software products have different ways of working with such orders and some have elected not to tackle it at all (ie ChannelAdvisor).

Back onto topic, we have the invoice, the courier label and we then ship that order off to the customer. Happy Days right?

We then have at least a carrier that was used and most likely a tracking number. These details then need to be passed back to the order source, so that the customer can be updated and in the case of Amazon, so you can get paid.

This involves another call back to the marketplace or order source (for example the Magento website) to update the order and change it’s status to shipped. And most likely at the same time, the inventory system has been altered to confirm that item has sold, a record was kept and possibly an email was sent out too.

Not as straight-forwards as it looked originally?

Generally there are two ways that multi-channel software providers will charge you:

• Fixed price
• Percentage of sale

Some multichannel software providers go with a tiered system, if you have X number of products or orders then you pay this amount and the cost increases the more products and sales that you make.

Others go with a percentage of sale. It’s this one where the costs can really spiral out of control and it’s no uncommon to find businesses paying £30K, £50K or even £80 or £120k a year to such providers.

Yes, obviously they’re turning over millions, but at these kind of numbers, we’re getting into the territories of buying houses with the amounts being paid to multi-channel software providers.

There is another billing method worth noting here, is that it’s pay per user. So you pay say £80 per user head in the business to use the software.

It doesn’t really matter how you cut it, the more you sell, the more you should expect to pay.

How much you’re actually willing to pay is a completely different topic!

The thing is, up until now the current 2nd generation providers have been building their own bespoke systems to cope with inventory, orders, the marketplaces & other business rules. This takes a shed load of time and a lot of money.

As the software grows, so does the complexity (and we’ve already seen some of the complexities including in the basic 5 steps, create, list, collect, process, update) which then adds in the requirement for an on-boarding team, staff that can help businesses migrate to the new software and of course a development team to keep everything working as it should.

I know from personal experience of doing this twice, first time around at Marketworks (eBay auction management software), also doing this myself with my own business, migrating to a software product can be painful, especially if prior to the migration all you’ve been using is the eBay Sell Your Item form or 1st generation or proprietary software like Turbo Lister.

Oh and the second time around at eSellerPro, sometimes it can take months. Every business is different and so are their requirements and it’s not as straight-forwards as it looks.

The more customers that are added, the more depends are put on the software to do feature x, y and z. Some multi-channel software providers just draw the line in the sand (ChannelAdvisor is a good example of this) and “say we do this”, then find partners for everything else. And others try and do everything under one roof.

We’re also missing a sales team, support staff & marketing, oh and a management layer as well somewhere too.

Everything & everyone has to be paid for.

Any multi-channel software is good software. I whole-heartedly believe that.

A business even using excel has a competitive advantage over a business that isn’t using excel. It’s that simple.

Remember those 5 stages create, list, collect, process, update from the beginning? Even simple nowadays is complex when it comes to managing multiple marketplaces and this complexity causes overheads, costs that need to be accounted for.

The thing is that some of these multichannel software providers (some with the help of myself) have taken the level of complexity, features and options to a whole new level, levels that were not thought possible only a few years ago and it’s the percentage of sale software providers that can get really, really expensive, the more you sell, the more you pay. It sounds nice, but the thing is, it gets to a stage where the amounts being paid is just plain silly.