Running an Online Channel

This page is for whoever runs GadgetSphere’s online shops day to day: the listings, the stock the shops show, the orders that must leave on time, the returns and disputes, and the scorecard each platform keeps on you. BigLedger brings the orders in and pushes your stock and prices out. Most of this job happens somewhere else: in the platform’s seller centre, in the packing area, and in decisions nobody has written down. For each part of the job, this page says what BigLedger does and who does the rest, when they do it, and how they know it is right.

The mechanics are on the E-Commerce module pages, above all Core Concepts and Best Practices. The money side has its own page: Reconciling Marketplace Payouts.

Meet GadgetSphere Online

GadgetSphere Online Sdn Bhd (GSO) is the group’s e-commerce arm. It runs its own storefront and sells on four marketplaces, and each marketplace shop is a marketplace branch in BigLedger. All of them sell from the same fulfilment-centre stock. On a normal day the shops together sell about 30 flagship smartphones. On a platform sale day they sell ten times that, most of it in the first two hours.

Before you start

• Each marketplace shop is set up as a marketplace branch, with its orders arriving (E-Commerce configuration).
• You can sign in to each platform’s seller centre, and to your payment gateway’s merchant portal if you run your own storefront. Most of this job is done there.
• You know who in the business packs, who raises credit notes, and who owns personal-data compliance. Several steps below hand work to one of them.

What BigLedger does and what stays with you

Step 1: Decide what each listing promises, and keep it true

A listing is a public promise. The title, the images, the specification, the variant and the price must each match the unit you will actually ship. The platform penalises a mismatch through returns, disputes and ranking. BigLedger does not check any of this against the item.

The caution that is not on the screen: when you link an item to a shop, the listing takes its own copy of the main image and the dimensions. Change the item afterwards and the shop does not change (EcomSync setup, step 6). Suppose a supplier substitutes a charger model, or a colour is discontinued. The item record in BigLedger can be right while the live listing is still wrong.

• Who: the channel manager, whenever purchasing reports a substitution or a specification change. Once a month, check your top-selling listings against the goods on the shelf.
• How you know it is right: for the twenty listings that sell most, the shop’s title, main image and specification match a unit taken from the shelf. After any substitution, re-link the item or edit the listing, then look at the shop.

Price per channel is a decision BigLedger will carry out, and it will not make it for you. Each marketplace branch has its own Default Pricing scheme. When you change it, every price in the new scheme is queued to the shop straight away. Charging more on a marketplace, to cover its commission, is a normal choice. It becomes hard to defend if your own storefront undercuts the marketplace in a way the platform’s price rules forbid. That is a commercial decision for the channel manager and finance, made before anyone changes the scheme, and never during a live campaign. You know it is right when the price on each shop matches the scheme you meant to use, and the seller centre shows no price-rule warning.

Step 2: Choose how much stock each shop may show, and size the buffer from the arithmetic

There are four ways to share one pool of stock among several shops:

1. Show everything everywhere.
2. Hold a buffer back.
3. Show each shop only a share.
4. Dedicate stock to a shop.

BigLedger carries out two of them on each marketplace branch’s Stock Configuration:

• A quantity buffer subtracts a fixed number of units.
• A percentage publishes that share of what is left. 100 publishes everything, and 10 publishes a tenth.

Splitting the pool and dedicating stock are not settings. The channel manager does them by hand, with a lower percentage on the shops that must not take everything, or by keeping the dedicated units in a location the channel does not sell from.

Size the buffer from what can sell before BigLedger knows about it. No screen tells you the number. Two things decide it:

• Orders arrive faster than stock leaves. A marketplace order is a sales order, and a sales order does not move stock. Nor does a delivery document. The units leave the stock balance only when the sales invoice is finalised. Until then they still count as available. The deduction for open channel orders does not help: it counts cancelled, shipped and delivered orders, skips the ones that have just arrived, and counts every channel line as one unit however many were bought (Core Concepts §3).
• The shop holds the old figure until the next push.

So a buffer must cover everything the other channels can sell between an order arriving and its stock leaving the balance, plus one push interval. For GadgetSphere’s flagship phone, suppose orders are invoiced twice a day and stock is pushed every two hours. On a normal day that is half a day’s sales across all shops (15) plus two hours’ worth (about 3): a buffer of about 18 units. On a sale day it is ten times that. Raise the buffer the day before a campaign and lower it the day after. Invoicing marketplace orders more often shrinks the buffer you need more than any setting does.

• Who: the channel manager. Set it when a shop opens, review it monthly, and change it before every campaign.
• How you know it is right: no oversold orders in the seller centre over the period. If a buffer-sized gap between the shop and your own figure turns into a much larger gap, count the cancelled channel orders for that item: each one is still holding stock back.

An oversell is the channel manager’s decision, and the clock is the platform’s. BigLedger cannot stop an oversell, because it never reserves stock for an order. When one happens, decide the same day:

• Source the unit. Transfer it from a branch.
• Substitute it, with the buyer’s agreement.
• Cancel it. The platform counts a seller cancellation against you (Step 6).

You know it went right when no oversold order was still open at its ship-by date.

Step 3: Ship by the platform’s date, not yours

A marketplace sets the ship-by date. Miss it and your late-shipment rate rises, which can cost you ranking or, eventually, the account. BigLedger stores Shopee’s ship-by date on the order, but no screen shows it, so the date cannot be your work list.

• Who: the packing lead, at the start of each packing round.
• What they use: the seller centre’s to ship list, sorted by deadline. That list is the platform’s own view of what it will count as late. Pack from it, then update the status from BigLedger’s bulk-update listing or from the seller centre.
• How you know it is right: the seller centre shows no order past its ship-by date. Over a week, the late-shipment rate on the platform’s scorecard stays below its threshold.

Some orders cannot make the date. Shipping late or cancelling is a platform-policy choice with a metric attached, not a free choice. Make it before the date passes, not after.

A failed delivery comes back as a status, not as stock. When the courier returns a parcel, the goods are yours again and they are in your warehouse. BigLedger’s stock balance does not know that until somebody records it (Step 4).

Step 4: Handle cancellations and returns: the platform decides, you correct the books

What BigLedger does with a cancellation: the cancellation job writes the channel’s status onto the order, and that is all. The order stays FINAL. Nothing is voided and no invoice is reversed. The cancelled order then goes on holding stock back from the shops (Step 2).

If an invoice was already raised for an order that is then cancelled, the invoice stays too. Accounts raise a credit note for it, and the monthly check below covers cancellations as well as returns.

What BigLedger does with a return: nothing arrives except the status. No job brings a return, a refund or a return-to-sender into BigLedger as a document.

So the correction is a person’s job. It happens in two places, in this order:

1. The goods, when they physically arrive. The stock keeper inspects the parcel. Decide whether the unit goes back to saleable stock, to refurbishment, or is written off. For a phone or laptop, check the serial number against what was shipped before anything else.
2. The books, when the goods have been inspected, not when the platform approves the refund. The accounts clerk raises the sales return or credit note against the invoice, as for any other sale (Returns and exchanges). A refund the platform gives after it has paid you out is taken back from a later payout. That half is on Reconciling Marketplace Payouts.

• How you know it is right: once a month, export the platform’s list of returned and refunded orders. Every one should have a credit note on that marketplace branch, and every returned unit should be back in stock or written off. An order with a refund and no credit note means your sales are overstated by that amount.

Separate the two duties. The person who approves a refund in the seller centre should not also raise the credit note and reconcile the payout. Put approval with the channel manager and the credit note with accounts. Then a refund that nobody can explain shows up as a gap between two people’s records, rather than disappearing into one person’s.

Step 5: Answer disputes and chargebacks with evidence you kept before you needed it

On a marketplace, the platform decides disputes. When a buyer says the box was empty or the item was different, the platform rules. BigLedger has no part in it. Your only defence is evidence, and it must be collected at packing time: a photo or short video of the unit and its serial number going into the parcel, and the parcel’s weight at hand-over.

• Who: the packing lead collects it. The channel manager submits it inside the platform’s window, which is short and set by the platform.
• How you know it is right: for any disputed order, you can produce the packing record in minutes. Keep a monthly count of disputes lost for lack of evidence.

On your own storefront, a card chargeback is yours, not the platform’s. A marketplace absorbs card disputes. Your own website does not. The card-holder’s bank takes the money back through your payment gateway, and you have a fixed window to contest it. BigLedger receives the gateway’s payment result and receives nothing about a chargeback. It also sends no refunds to the gateway.

The storefront’s Request Refund widget does not refund anything either. It sends an e-mail, with the invoice number, reason and the shopper’s contact details, to the address set on the widget in CP Commerce Admin.

• Who: whoever holds the gateway’s merchant portal login watches it for dispute notices. Whoever receives the Request Refund e-mail refunds through the gateway, then asks accounts to record it.
• When: check the merchant portal weekly, and daily around sale periods. The contest window starts when the bank raises the dispute, not when you notice it.
• How you know it is right: every chargeback and refund in the gateway’s report for the month has a matching credit note or refund voucher in BigLedger. The Request Refund mailbox has no request older than your promised response time.

Step 6: Keep the platform’s scorecard healthy, because BigLedger cannot see it

Every marketplace scores your shop on its own measures:

• late shipment
• seller cancellation
• return rate
• chat response time
• rating

Slip too far on any of them and you lose visibility, campaign slots, or the account. None of these numbers exists in BigLedger. The seller centre is the only place to read them.

• Who: the channel manager, weekly, and daily during a campaign.
• What BigLedger can help with: Steps 2 and 3 are the inputs you control from here. An accurate buffer keeps seller cancellations down, and working from the to-ship list keeps late shipments down.

Reviews and buyer messages. BigLedger pulls Shopee and Lazada reviews, and sends the replies you write from its Reply To Review screen. It also syncs Shopee conversations. It never writes a reply. A public reply is written for the next buyer, not only this one: say what you did about the problem, and stay inside the platform’s response window. The channel manager, or someone they name, replies daily. You know it is right when no review in the reply queue is older than the platform’s window.

Campaigns are a stock and margin commitment. Joining a platform sale day usually means a price cut, sometimes a voucher you part-fund, and a promise of stock. BigLedger will push whatever price and stock you set, and has no view on whether the campaign pays. Before you join, the channel manager and finance should agree three things:

1. The margin after the campaign discount and the platform’s fees (Reconciling Marketplace Payouts).
2. The stock you are committing.
3. The buffer for the day (Step 2).

After the campaign, finance compares the margin agreed with the margin the next payouts show. That is how you know whether to join the next one.

A suspension or payout hold stops new orders or new money. It does not cancel what you already owe: open orders still have to ship by their dates. BigLedger keeps pulling whatever the platform returns. Keep the ship-by list moving, and tell accounts, because payouts will stop matching.

Step 7: Decide what the buyer’s personal data is for, before the first order arrives

Every marketplace order brings the recipient’s name, phone number and full delivery address, and BigLedger writes them onto the order. Which customer the order is billed to depends on the marketplace, and on two of them it is a choice on the marketplace branch that is easy to miss.

Shopee and Lazada (a Shopify shop reads the same setting):

• Default Entity ticked, with an entity chosen: every order from that shop is billed to that one customer, for example “Shopee buyers”. No customer record is created per buyer. The delivery details stay on each order.
• Default Entity not ticked: BigLedger looks for an existing customer with the same name and phone number, and creates one, with the address, if there is none. Over a year this builds a customer list of every marketplace buyer.

TikTok Shop: there is no choice. The TikTok order job does not read Default Entity, so ticking it on a TikTok branch changes nothing. Every order is billed to a customer record for its buyer, keyed on the buyer’s TikTok user id: the buyer’s first order creates the record, with that id as its customer code and the buyer’s name, phone and address, and each later order finds it by the id and replaces the address with the latest delivery address.

Each design has a cost. One customer per shop keeps your customer list clean and holds no personal data outside the orders, but you cannot see a repeat buyer. One per buyer lets you see repeat buyers. On Shopee and Lazada the matching is on name and phone, so a platform that masks phone numbers, or two people with the same name, will merge different buyers or split one buyer across several records. On TikTok Shop the platform’s id keeps one buyer to one record, but the record’s address is only ever the latest one. Either way, it creates a customer list of people who agreed to nothing with you: they bought on the platform’s terms, not yours. And it makes the payout reconciliation much heavier: a receipt voucher is made out to one customer, so a weekly settlement of 300 orders needs 300 vouchers instead of one (Reconciling Marketplace Payouts, Step 2). A TikTok shop always carries both costs.

• Who: the person responsible for personal data in the business decides, with the channel manager, when each shop is set up. The decision includes what the customer records may be used for. Delivery and after-sales service are what the buyer expects. Before any marketing use, check it with whoever owns personal-data compliance in the business, because the buyer never gave you consent.
• When a buyer asks to be forgotten: the customer record’s contact details can be dealt with, but the order and the invoice are tax records and stay.
• For a TikTok shop, the decision is only about use, because the records will exist. The data owner writes down what they may be used for when the shop is set up, and the channel manager tells whoever handles customer records that TikTok buyers arrive as customers on their own, with a long numeric customer code (the buyer’s TikTok id).
• How you know it is right: the decision is written down for each shop, and nobody has imported the marketplace customers into a marketing list. On a TikTok shop, open any recent order’s customer: its code is the buyer’s TikTok id, not the customer you may have chosen as Default Entity.

Step 8: Notice when a feed stops, because nothing will tell you

Marketplace orders arrive numbered and FINAL, with no queue of unworked documents. When a channel stops, BigLedger shows a quiet day. The check, and what to do when it fails, are on Best Practices §6 and in Sales That Arrive From Another System. The occupation’s half is who:

• Who: name one person per shop. Each morning they compare yesterday’s order count in the seller centre with yesterday’s sales orders on that marketplace branch.
• The alert BigLedger does send: when an order holds an item that is not linked, the Missing Order Items e-mail goes to the address list on the order job. Make sure that list names a person who is at work, not an old shared mailbox. Linking the item does not bring the order back by itself.
• How you know it is right: the two counts matched yesterday, or someone has written down why they did not.

Step 9: Judge whether a channel pays, after its costs

Each shop is its own branch, so the Sales Report filtered by branch gives each channel’s sales. That is gross revenue, and it flatters a marketplace. The marketplace’s commission, fees, shipping and co-funded vouchers come off before you are paid. Your storefront carries gateway fees and its own delivery cost instead. Order prices arrive already net of the platform’s discount, with no separate discount amount. So a platform-funded voucher leaves no trace on your side at all.

A fair comparison is contribution after channel costs. You can produce it only if the fees are booked to their own accounts, per channel. That is the main reason to follow Reconciling Marketplace Payouts rather than booking the net payout as if it were the sale. BigLedger has no channel-profitability report.

• Who: finance, monthly or quarterly. The channel manager supplies the campaign and voucher context.
• How you know it is right: each channel’s contribution for the period fits on one page, with the fees by type, and the channel manager recognises the numbers.
• What to ask: did the channel add sales, or move shoppers who would have bought in a branch or on the storefront anyway? Look at whether branch and storefront sales in the same categories fell when the channel grew. A channel that loses money can still be worth keeping for reach or to clear stock. Write the reason down, so the question is asked again next year rather than forgotten.

What success looks like

Run these in a few minutes at the end of a month:

1. Yesterday’s order count in each seller centre matches the orders on its marketplace branch.
2. The platform’s returned and refunded orders for the month each have a credit note in BigLedger.
3. The gateway’s chargebacks and refunds for the month each have a matching entry in BigLedger.
4. There were no oversold orders, and each shop’s buffer has been reviewed since the last campaign.
5. The late-shipment and cancellation rates on each scorecard are inside the platform’s thresholds.
6. For each shop, a written note says how buyers’ data is held, and who owns the scorecard, the morning count and the Request Refund mailbox.

Common mistakes

Related documentation

• Reconciling Marketplace Payouts: the money the platform holds for you, and how to prove it at month end
• Core Concepts: the stock calculation, the order paths and the gateway payment
• Best Practices: the setup and monitoring advice that follows from the mechanics
• EcomSync related applets: every job, the setup order and the troubleshooting table
• Organisation Applet: the marketplace branch, its Stock Configuration and Default Entity
• Returns and exchanges and Sales That Arrive From Another System