Yaadibook: Building an app for quick billing and inventory management for Pharmacies in Bharat — A UX Case Study

In this case study, I’ll talk about an unlaunched venture I co-founded and the challenges I faced while designing the product.

Waqar Khan
11 min readMay 22, 2024

🧾Project Information

Timeline: Jul’20–Apr’21 • 10 months

Role: Co-founder (of an unlaunched venture)

Sector: Pharmacy Billing, Point Of Sale (POS), ERP

Status: Dropped it due to Covid-19 and personal reasons (details at the end)

After COVID-19 hit the world, it became necessary to practice social distancing. Even though people wanted to avoid public spaces, they were forced to visit the local pharmacy and spend a long time standing in queues which increased the exposure to the virus and its transmission.

My friend noticed this problem while buying medicines during the lockdown. We studied this problem for a few months and brainstormed solutions around it.

After feeling confident that a market existed for our newfound understanding of the problem, we decided to pursue this full-time quitting our jobs, pretty scary I know, and I moved to Bangalore with him. This was also my first time working on such an aspirational project as my own boss.

Dear reader, this is going to be a detailed case study and it might take you few minutes to go through it but I promise that you will learn a thing or two in the end. Let’s get started!

🔌Understanding the root problem

Let’s imagine you visited a local pharmacy to buy medicines. On average you have to wait around ~8 minutes (yes I timed it) for:

  1. communicating the medicine(s) to be bought,
  2. the pharmacist to fetch the medicine(s) from the inventory,
  3. you to make the payment and,
  4. for them to generate a bill (let’s be honest, they generally don’t, but why?)

The current setup of the Indian Pharmacist doesn’t incentivise them to generate bills on the go since it can be time-consuming depending upon their setup.

Generally a setup contains two things → a software + the physical storing and labelling of their medicine boxes for fetching.

It is a standard practice for them to maintain a rough register to quickly note down the sale and update it later all at once when there is less customer footfall.

Now let’s understand how a simple sale is carried out at a pharmacy in India from the pharmacist's point of view:

  1. The customer asks you for a medicine
  2. You fetch the medicine box (usually marked from A-Z) containing the medicine
  3. Once you find the box, you search for the specific medicine from a pile of medicines. Sometimes the medicine can be out of stock.
  4. If the medicine is in stock then you make the sale. If not then,
  5. You suggest a different medicine to the customer with the same ingredients.
  6. If he disagrees, you lose a sale because you failed to keep the medicine in stock. If he agrees then you make the sale.
  7. You then write down the out-of-stock medicine in your rough register, contact the supplier to purchase the medicine, and wait a day or two to receive it.
  8. Since you did not generate a bill for the customer, your inventory is not updated with every sale and you cannot order the medicines out of stock as early as possible.

Despite its current appearance of speed by not generating a bill, this process merely postpones the inevitable i:e, an increasing debt of unfinished tasks that must be settled later or delegated to someone else at a cost.

Generating bills to multiple customers simultaneously during peak hours is also not possible on the existing setup because of software limitations. Managing the inventory is a tedious task as well. Although existing software provided billing & inventory management solutions, we saw them struggling during COVID-19 when the demands for medicines were high.

Do you see it now? The root problem of the long wait time was a poor digital infrastructure to run the pharmacy which included an inefficient billing system and a complex inventory management.

💭Hypothesis

The slow fetching and billing of the medicines at the pharmacy were due to their existing setup which resulted in long wait times, and poor management of the pharmacy resulting in higher maintenance costs at the end of the day.

🧭Validating our hypothesis

We targeted Tier 2 & 3 cities for our research where we observed this problem to be more prevalent.

Tier 1 cities were usually organized and equipped with expensive management systems, higher revenues, and a skilled human workforce to help with inventory management. What was required in Tier 2 & 3 cities was a low-cost alternative to manage the pharmacy.

Tier 2 city — Nagpur

So what happens behind the scenes and what did we learn?

  • Even though a few people liked the existing system, almost all unanimously agreed that billing multiple people during busy hours is almost impossible & inefficient. This is why they skip giving bills to people unless they are specifically being asked for.
  • The current practice adopted in the industry is to generate a bill for the customer who asks for it, and for the rest of them, a physical rough notebook is maintained where the pharmacist quickly jots down the sold items which is later updated into the system collectively.
  • The upside of this practice was that it saved the pharmacists time and effort during rush hours, but the downside was to update the inventory late at night after a rush hour or early morning before opening the pharmacy. Although generating a bill means automatically updating the inventory in real-time, but there was too much friction in this process.
  • The majority of pharmacies hire a data entry person who feeds this pending data into the system. They usually charge 5k to 20k for this job depending on the pharmacy, workload, and the city. This increased the pharmacy management cost.
  • A register a.k.a Yaadi was used to maintain records instead of updating everything in the system directly and instantly.
  • All the existing software that we saw was complicated and required skilled individuals who knew how to operate the computer.
  • Online/offline courses on learning how to use the software were also necessary for the majority of these first-time employees since there was a steep learning curve and not intuitive with poor UI/UX.

A typical cost of managing a pharmacy looked something like this 👇🏻

As seen above:

  • The cost of purchasing software → Cheapest starts at ₹6,000/- to ₹25,000/- one-time cost and other companies provide software solutions on a subscription basis starting at ₹3,000 user/year. to ₹5,000
  • Cost of employing a data entry person₹5,000 to ₹20,000 per month
  • Cost of maintenance→ Varies from ₹1500/- to ₹3000/- annually. This includes monthly manual backup by the software agency, support for technical issues, and troubleshooting.
  • Other miscellaneous costs include → Printer ink, stationery items, billing paper rolls, electricity cost, etc.

Tier 3 city → Chakiya (Small town near Varanasi)

Similar problems as above were identified in this city along with some new and interesting problems.

  • To our amazement, some pharmacies here were still using the old pen-and-paper method purely to generate bills & maintain their inventory. They even handed out “Kaccha” bills to the customers when they asked for a bill.
  • Due to the lack of a skilled workforce, maintaining the inventory using a computer was not possible, hence they avoided buying the setup.
  • People did not trust computer technology yet even though they used smartphones.
  • There were pharmacies operated by pharmacists who barely knew how to read and write English. The qualifications & degrees of these pharmacists were highly questionable.
  • No regulatory or proper rules are being enforced by the authorities or the pharmacy union in these cities.
  • You didn’t require a prescription but a relation with the pharmacist to buy prescription medicines.

🔻Existing software limitations

In no particular order, these were the observed limitations of the software that were majorly used by pharmacists:

  1. Offline
  2. Expensive
  3. Poor UI/UX
  4. Billing slowly
  5. Unable to connect to a cloud storage or backup frequently
  6. If the HDD crashes, the entire pharmacy must manage on pen & paper until things are restored, resulting in data loss
  7. No GST calculation and filing
  8. No mobile app support
  9. One computer allowed billing for 1 customer at a time, thus increasing the wait time for all the customers
  10. Difficult to operate and you need to train a person to use the software
  11. No Live Sync between mobile and desktop applications
  12. Quick Billing Counter unavailable (Barcode + Voice)
  13. No real-time cloud backup
  14. No historical data on the patient

Our hypothesis was successfully validated that the existing system of managing the pharmacies could have been more efficient, mostly due to the existing software used to manage them and the expertise required to operate them.

👥Competitor Analysis

Once we understood our core problem to be solved, we started looking if this was already solved or not. If yes, then was there scope for improvement?

Here are brief insights for our major competitor after our analysis;

Marg ERP: One of the biggest players in this space who processes 20 billion invoices per year. They had a comparable monopoly like Tally for the Accounting Industry which had the potential to be disrupted because they were getting too outdated with their existing software and the advent of next genertation of pharmacists entering the fold. They did not have mobile support.

GoFrugal: Another competitor that is fully desktop with a basic user experience and a steep learning curve to use it.

OkPharma: Although above-average UX but a terrible UI, navigating the app was a nightmare and unusable. People switched to their desktop version instead of using the mobile app.

Vyapar: A generalised billing and inventory management solution for all businesses, not optimised for fast pharmacy billing at scale.

Flobooks (now MyBillBook): They are doing similar work but across all categories, they were not specific to this niche hence their UI is also a bit generalised to cover all the use cases of different types of users. But an impressive app and execution overall, we liked it!

Few insights we gathered after observing our competitors

  1. Patients can receive the bill instantly on their mobile, which they can print later if they need a hard copy in the future—reducing the pharmacy printer cost and reducint the billing time.
  2. Small thermal printers connected to individual employee’s mobile via bluetooth can be used to allow generating multiple bills at the same time by sending individual commands for prints.
  3. Once we have enough data on a single pharmacy, we can further optimise their inventory management by giving insights on the most running items in their inventory to minimize instances of medicines to go out of stock.

🦚Refined Problem Statement

To build a mobile app and make the entire billing and inventory management process simple, fast, and intuitive.

KPIs

  • Billing 1 item should not take more than 30 seconds.
  • Anyone with the basic knowledge of operating day to day apps, should be able to learn how to manage the pharmacy, inventory using mobile.

🌌Solution Space

We have designed a mobile application for quick billing and managing the inventory simultaneously by multiple people to increase overall efficiency in running the store & to reduce the crowd on the counter.

Information Architecture✗ Database Schema ✔

Ideally, there should’ve been an Information Architecture but working in fast teams where time & energy are vital, our database schema was the information architecture for my designs.

Initial view of the database schema, it was a work in progress.

//skippable side note

Thank you for making it this far, and here’s the reason for YaadiBook being an “unlaunched” venture as stated above…

The design, development, and user testing were still a work in progress until the 2nd wave of Covid-19 hit India with high mortality rates. We both lost our family members which also included my father. Personally, I had to put a pin on my design career and come back home, take care of my family, and look after my dad’s 36-year old business.

But hey, that is life… every soul shall taste death, right? My recent experience gave me a new perspective on how short & unpredictable life can be. This time of reflection has been invaluable, helping me realize that I want to do meaningful work that truly helps others. I’m back in the grind now, driven by a renewed commitment to make a positive impact on other people’s lives.

Moving on!

Visual Designs

There have been 2 very prominent iterations of the entire visual design which was revamped once we got a better understanding of the market and what worked. A lot of things were well-researched but yet to be designed and tested with users. Here are the ones that were designed on priority.

Edge case to be solved for the above flow: Selling the last remaining medicine to two different customers at the same time. We can do this by having a real-time checking of the billing cart so that even if 1 employee adds the medicine to the cart, the other person cannot add the same medicine and will get an alert that the same medicine has already been added to someone else’s cart. This is one possible solution.

Results

  • We couldn’t develop and test the features to validate our solutions with pharmacies because of the reasons mentioned above.
  • But I was very confident in my research, and the design direction we were taking at the time. Today we see many players who have cracked the market in the POS space like PineLabs, AIBillingSystems, and the significant growth of MyBillBook. Further validating that we were on the right track.

Future Scope?

  • Adding support for native language to improve adoption in Tier 3 cities.
  • Can look into a business model where we look at partnering with pharmaceutical giants to promote their products to keep the application completely free for all pharmacies.

Learnings and Key Takeaways

  • My biggest learning was that we were optimising for “time” in a money-minded Indian market, so there needs to be more incentive to use the product than just fast billing.
  • The depth of the application to be designed and developed was immensely huge once we got into it. We probably underestimated the scope of the project but the entire management experience is very detailed and nuanced in how the industry functions in India.
  • Navigating differing viewpoints between founders on the product can be challenging, but learning to think critically under pressure is good.
  • Although we did not test the product, I learned that the best product doesn’t always win. The market is very nuanced with lots of variables.

Looking for full-time Product Design roles!

If you found this case study worthy of an interview call then let’s connect on:
LinkedIn,
Twitter (X), or drop a mail at,
waqarkhandesign@gmail.com

Check out my other case studies → here.

👏🏻 If you’ve made it this far, feel free to give 50 claps— your perseverance deserves applause. Thanks!

--

--

Waqar Khan
Waqar Khan

No responses yet