Returns Tracker

Automating the order returns process for e-commerce

Visit Website
November 27, 2019 Closing down Returns Tracker

With returns tracker, I set out to help a friend's e-commerce business automate their return order refunds. I thought I could build a small, but useful tool, and that if my one customer was happy, I could sell it to other e-commerce companies as well.

I didn't have the coding skills, but I thought I understood the payments domain well enough to be able to pick up the coding skills I needed, and build something useful.

I've really enjoyed learning to work with React and Python. Perhaps too much, as I could have used that time to work with my client to design a full solution, and do a bit of customer discovery to validate the problem I was tackling.

In the last few weeks, I've focused my time on customer discovery. I've had the pleasure to talk to a range of very smart people about return payments, and payments more generally.

Turns out, this project isn't going to succeed. Below, I explain where I went wrong.

Returns tracker is essentially a process automation tool. When automating processes, you are doing one of two things:

  1. Reinventing a process to make it more efficient using technology.
  2. Mapping an existing process and automating the parts that can be automated without changing the process.

The first approach will result in a product. The second approach will result in a consulting business.

Without realising it, I was going down the second path. Since my aim was to build a product, that's not good.

Here's how I failed:

To reinvent a process you need to have deep domain knowledge. I found myself out of my depth in the e-commerce order management space.

I would solve one problem, only to find out from my client that there are three more steps in the process I wasn't aware of. This happened several times.

As of now, I've got a list of seven separate APIs I need to connect with to automate the returns process:

  • Warehouse system order management REST AP
  • Warehouse system legacy status SOAP API
  • Postage slip system
  • CRM tool
  • Notifications system
  • TransferWise payments API
  • Klarna payments API

I also discovered that my client's plans to replace card refunds with bank transfers would expose them to chargeback risks. Cutting out card payments from the process meant reducing the number of returns payments I could automate significantly.

In addition to API integrations, I needed to build:

  • A back office tool with approval flows for managing return orders
  • A customer-facing return management portal
  • A notification system.
  • An order status tracking feature

At this point, I realised it was clearly going to be a custom build just for them. Is doing a custom solution such a bad thing? It depends on the size of the problem.

Unfortunately, I knew from the start based on some the number of return orders they process that the amount of time I could save for my client wouldn't be enough to make this a viable project stand alone project. While building it out has been fun, committing to maintaining all those integration (with no upside, as it would be a one-off integration) wasn't something I would enjoy.

So, I am now going "Indie Hackers Official" with closing down.

it's been fun, and I've really enjoyed the support the Indie Hackers community has provided. I've gotten to meet some fantastic people here.

I've salvaged the useful bits of the work, which is an NPM package for collecting bank account details, and a back office tool for integrating to TransferWise and other payment providers.

Perhaps the most fun bit was when someone on Twitter decided to contribute additional language support to the NPM package. The Internet is truly awesome for collaboration.

Here are the stats on the Bankdeets.co NPM package I published:

  • 1004 NPM downloads
  • 42 currencies added
  • 6 languages
  • 6 stars on Github
  • 3 forks
  • 17 unique clones
  • One contributor

Even more fun, I've got a few people interested in using this in production. That's pretty exciting, and if it becomes a reality, I will consider this project a success.

Comment

October 24, 2019 Published my first NPM package

I've published <BankDeets/> on npm, a React form for collecting bank details in any currency, compatible with
TransferWise
.

http://bankdeets.co (or npm install bankdeets)

  • SWIFT and local payments
  • 20 currencies
  • Translations (en, sv, dk, no, fi)

TransferWise uses local banks around the world to make payments cheaper and faster.

But local formats vary, and you might feel like you need to be a bank details expert to get the right info.

No longer. Try for yourself: http://bankdeets.co.

Why did I build it? With http://returnstracker.com, I'm helping a friend's ecomerce business improve their return order process.

We needed to collect bank details in multiple currencies that works with TransferWise. Hence BankDeets.

6 Comments

  1. 1

    Just checked your code.
    Did you think about using RollupJS for creating package?
    I'm using it for my components and i'm pretty happy with result

    1. 1

      I had a look at Rollup, and it looks interesting. I actually wanted to accomplish the same thing by creating the npm package.

      Would using Rollup mean I can distribute it as a javascript package as well, without using NPM?

      1. 1

        Rollup will do the same thing as webpack. it's just another way, and rollup was less confusing for me to start. Webpack is looks so scary :) it's for creating your bundle.

        you'll still need to publish code at npm. another option is to use github registry - is a new feature, but npm is still King of the Hill...

  2. 1

    do you have github link for that? will star the repo.
    Btw, what do you think about publishing a story about creating this component at Hackernoon? it can get some exposure and more people will try it

    1. 2

      Thanks Arthur! GitHub link here: https://github.com/321k/bankdeets

      I didn't realise I could contribute to Hackernoon. Will definitely do that!

      1. 1

        Sure you can -if you need help with that - buzz me

October 17, 2019 Alpha version live

The first version of Returns Tracker is now live!

  • Customer can select their order and request a return
  • Merchant can approve return and create return order
  • Connect to warehouse system (Ongoing WMS)
  • Connect to payment system (TransferWise)

Try it out from the customer's perspective here:
https://returnstracker.com/home/melon-co?goodsOwnerOrderId=102&email=test@email.com

Comment

September 22, 2019 Basic scaffolding in place

It's day 7/42 and I now have the basic scaffolding in place for the app:

  • API built in Flask with basic test coverage
  • Database set up using Postgres
  • Minimal front end built in React with Material UI
  • Payment and warehouse test credentials
  • Merchant and shopper authorisation with Flask-User
  • Website deployed to Heroku on returnstracker.com

The next week will be spend defining the user flows for the shopper.

If all goes well, I will have time to built a minimal returns flow and do a test with live data by the end of next week.

1 Comment

  1. 1

    This comment was deleted 7 years ago

    1. 1

      Thanks :)

September 18, 2019 Getting started: first customer interview

I'm on a six week mission to build and launch a niche SaaS app for automating customer returns in e-commerce. It is now day 3/42.

Start date: 16 September

My goal is to learn how to write a web applications and to get a paying customer.

I want to make sure I'm building something that works for my potential customers, so one of the first things I did was enlist my friend who runs an e-commerce site to get a deeper understanding of the industry.

Interview here: https://medium.com/@321K/the-eight-steps-of-a-customer-return-in-e-commerce-5e8ab5dfb0d6

Comment

About

One of the amazing perks of working at TransferWise is a six week sabbatical after four years on the job. I'm using these six weeks to build a niche SaaS company.