Year: 2020

06 Jul 2020

The FTL Dilemma

A client required an integration with a 3rd-party logistics company (3PL) to fulfil LTL & FTL shipments.

Background: While we customized the logic to automatically determine LTL or FTL needs for an order, little did we realize that the 3PL the client chose to integrate with did not support providing an instant quote via an API call for FTL shipments. Rather, it required to go through an internal manual process to get the best rates from different carriers.

This posed a problem since the business rules within checkout mandated to indicate the shipping cost to the customer prior to placing the order, whereas for FTL shipments we couldn’t get the rates instantly. We had to rule out the possibility of calculating and charging shipping costs post order placement as the client’s line of business meant shipping rates could be more expensive than the items themselves, therefore likely a huge variation between authorized and capture amounts. Hence it wasn’t an alternative, we simply had to let the end customer know the costs prior to them confirming the order.

Thus, came into being the FTL Dilemma.

The Problem Statement

We needed a checkout solution that supported FTL shipments and is also able to indicate cost of shipment prior to order placement.

How did we go about solving the problem?
We brainstormed various approaches with the 3PL provider and client.

Option 1: Default FTL rates

We looked at defaulting FTL rates to a standard $value prior to placing the order. This way, we can have the end customer place the order with standard FTL rates and calculate the actual rates during fulfilment. But we found that there were too many variables that can cause big fluctuations in the actual cost of shipment, hence zeroing on the default rate that seemed fair for every order was impossible.

Option 2: 1 FTL = multiple LTLs

We also evaluated splitting an FTL order into multiple LTLs to obtain costs and calculating FTL rates at the time of shipment. This option did not work for this solution, since the possible variations in post order scenarios meant a very complex and expensive customization. The client wasn’t very keen in an expensive solution for a problem perceived to be a rare occurrence.

Option 3: Leave it to the CS Agent

We discussed about simply recording the end customer’s request for an FTL order and notify the customer service team to assist the customer place the order. It required the CS agent to telecall or email the end customer and coordinate an offline ordering process. This was rejected by the client who quoted that they wanted some of the activities to be automated to reduce the overhead on Customer Service organization. Nevertheless, this option paved the way to finalize the eventual solution.

Option 4: Inform the customer

The option we finally zeroed is an extension of Option 3 and it was to simply notify the end customer in case of an FTL scenario and request them to await an email confirmation for costs before they could proceed with the order. As soon as the customer requests for an FTL order, notifications are sent to the CS organization and the 3PL service provider for determining shipment costs. The costs were then manually posted to the order via Backoffice which automatically triggered an email notification to the customer allowing them to proceed with the order.

FTL Dilemma – Solution Details

We built the solution, wherein for FTL orders – the end customer would be notified about it being a special order at the start of the checkout process. The system would save the cart so as it can be pulled back at a later time.

Internally, the system would send alert notifications to the client’s CS organization and the 3PL service provider about the order requiring an FTL quote. The service provider would then revert back with the shipping quote to the CS team, who diligently updates the specially created shipping charges attribute for this order via the Backoffice. This action by the CS agent, would automatically trigger a pre-configured email to the customer notifying the updated cost of the order due to the inclusion of FTL shipping costs. The customer can then proceed to retrieve the saved cart (which now has the shipping cost associated) and place the order. We also proactively put checks in place to reset the quote process in-case of any modifications to the cart items during order placement.

To conclude, this wasn’t the most elegant solution that we built, but was a compromise that ensured a win-win for all parties involved. At the end of it, that is what mattered.

Our solutions to challenges do not stop here, stay tuned for Refund Ramifications

14 Jun 2020

The PDF problem

In one of our recent implementations that required us to integrate a marketplace platform with a commerce platform, we faced an interesting operational problem that is often overlooked during design: The PDF problem.

Background: This was a new marketplace for overstock items that aimed at attracting sellers that wanted to liquidate their old stock.

While sellers were happy to sign-up and make some money on old stock, they weren’t particularly enthusiastic in spending work hours to enrich product content on some items destined to the yard for recycling. They wanted an easy way to associate product specifications that were in pdf format to their products on the website, else they would have to manually key them through the marketplace seller portal.
Client as the operator of the marketplace was principally inclined to provide product specification information on the PDP pages and hence obliged to seller’s request to upload the pdfs during product creation and not needing to key-in the information.

But alas, the marketplace platform did not support pdf upload at the time of our implementation. Hence came into being “The PDF problem.”

The PDF problem

The ask was to be able to associate a product specification pdf to a product during its creation in the seller portal within the marketplace platform.
The data along with the other product data (images, offer, product basic data etc.,) would then be transferred to the eCommerce platform and be displayed on the website. The issue arouses due to the fact the seller portal did not support upload of pdfs.

How did we solve

Pragiti’s analysis resulted in knowing that this is a business operations problem that required a technical solution. Our analysis resulted in the following findings

  1. The client as the operator mandated attaching a pdf spec sheet for all items on the website
  2. Not all sellers had a pdf spec sheet for the items they sell
  3. Few sellers had pdfs stored in their file systems
  4. Some sellers were able to only provide public URL references for the pdf spec sheet of individual product than to download and manually send them, simply due to the sheer volume of items

Based on the analysis, we came up with a solution that was cost effective, easy to use and was accepted by all parties involved.

Our approach was to ensure that irrespective of the seller’s approach to share the pdf spec sheet, we would create a consistent experience in product & offer creation, thereby keeping the impact on business operations minimal.

To address the challenge, we simply leveraged the existing IT infrastructure of the client and created a technical solution that adapted to the variations in sellers’ approach to pdf spec sheet and one that did not adversely disrupt existing operations.

  • Per the client’s need, we mandated the need for a pdf spec sheet for every product.
  • We defaulted to a standard ‘Spec sheet not available’ template for those items the seller did not have a pdf spec sheet.
  • We repurposed client’s unused server as a file server and made it available to sellers to securely access and upload the pdf spec sheet.
  • We created code to extract the pdf file from an URL and loaded it into a local file server that was not attached to the marketplace platform. We then simply referenced the file directly within the website.

It was a solution that we turned around in quick time and one that was effective in addressing all the variations. It was a gratifying experience to have used an IT solution to solve a business problem.

Up next is the ‘FTL Dilemma’ – stay tuned to know what was it and how we approached to solve the problem.