Case study 01

ZekiSales — AI-Powered SaaS POS & ERP

ERP · Retail · SaaS · Telegram Bot · AI Chatbot

A multi-tenant POS and ERP that lets retail, wholesale, and credit businesses run checkout, inventory, purchasing, and customer engagement from one system — designed around how cashiers and owners actually work, with a Telegram bot, an AI chatbot, and a support ticket system built into the experience.

My role
Product designer & UX researcher — research, UX/UI, design system
Platform
Responsive web app: desktop, tablet, and touch
Users
Cashiers, sales staff, branch and business admins, owners
Scope
40+ feature areas across POS, stock, purchasing, CRM, and reporting

−40% checkout time across wholesale, retail & credit customers

The challenge

High cognitive load and user errors by retail cashiers during peak hours — every extra tap cost real money on the floor. Wholesale and credit customers added more steps, and support ran through phone calls and WhatsApp messages.

What the product had to do

  • Make the common path — find an item, add it, take payment — possible without leaving the keyboard or hunting through menus, for retail, wholesale, and credit sales alike.
  • Keep a whole shift resilient to real life: interrupted sales, returning customers, split payments.
  • Give owners answers — reports, financial statements, stock, and purchase orders — wherever they are, without logging in and digging.
  • Move support out of phone calls and WhatsApp into something trackable.
  • Give owners control of stock, staff, and branches without cluttering the cashier’s screen.

Design process

Empathize

Spent time on live retail floors with cashiers, watching real checkouts.

  • Contextual inquiry on live retail floors
  • Field observation during peak rush windows

Define

Turned what I saw into three checkout bottlenecks and the cashier’s mental model.

  • Operator task analysis and error logging
  • Bottlenecks: nested menus, ambiguous tender flows, delayed feedback
  • Mental model: scan → total → cash

Ideate

Explored layouts and flows that follow how cashiers already think.

  • Two layouts for two kinds of cashier
  • One checkout for retail, wholesale and credit
  • Keyboard-first, interruption-proof sales

Prototype

Built the flows, prototypes and the interface system.

  • Checkout flows and interactive prototypes
  • Owner assistant: Telegram bot and AI chatbot
  • Interface system for the back office

Test

Tested with cashiers before anything was finalised, then refined with engineering through build.

  • Prototype usability testing with cashiers
  • Pilot team reported about −40% checkout time

Pain points

One layout slowed down one kind of cashier

Touch-first shops browse by category and tap; high-volume counters scan and type. One layout can’t serve both without slowing one down.

Wholesale and credit sales were slow and error-prone

Wholesale and credit customers need different prices and payment terms, and pushing them through the retail flow added steps and mistakes.

Menus broke the cashier’s flow

Cashiers think ‘scan, total, pay’. Menus that interrupted that order created hesitation and errors.

A lost cart meant re-scanning everything

A half-built cart lost to a refresh or a distracted moment meant re-scanning everything.

Hands full, keyboard out of reach

Cashiers handling products and bags can’t always reach the keyboard.

Owners dug through reports for simple answers

Owners away from the shop had to log in and dig through reports just to answer a simple question, or call the shop instead.

Support was scattered across calls and WhatsApp

Support happened over phone calls and WhatsApp: hard to track, easy to lose, and interrupting the shop floor.

Cashiers could see what only owners should

Owners need cost prices, margins, and permissions; cashiers need none of it — and seeing it is a risk.

Back-office screens were dense and overwhelming

Inventory with batches and expiry, purchase orders, transfers, and audits is dense by nature.

UX research methodology

  • Contextual inquiry on live retail floors
  • Field observation during peak rush windows
  • Operator task analysis & error logging
  • Prototype usability testing with cashiers

Key research insights

  • Three major checkout bottlenecks: nested menus, ambiguous tender flows, and delayed feedback after actions
  • Cashiers held mental models of ‘scan → total → cash’ — the UI forced a different order
  • Interrupted sales (a customer forgets something, a phone call) were common, and losing a half-built cart meant starting over
  • Owners wanted quick answers — how was today, what’s low on stock — far more often than they wanted to open a full report

Who we designed for

Nadeesha — Cashier, evening shift

Works the counter through the after-work rush, often with a queue and both hands full.

Goals

  • Keep the line moving without mistakes
  • Take payment in as few steps as possible
  • Recover quickly when a customer changes their mind

Frustrations

  • Nested menus that break her scan → total → pay rhythm
  • Losing a half-built cart when interrupted
  • Unclear split-payment steps

Kasun — Store owner, three branches

Checks sales and stock from his phone and wants control without being in every shop.

Goals

  • See sales, stock, and margins across branches
  • Get reports and stock answers by chat, without logging in
  • Control who can see cost prices and change stock

Frustrations

  • Needing to log in and dig for a single number
  • Stock counts that drift between branches
  • Calling the shop or the vendor just to get help

Ruwan — Branch manager

Runs the floor, reconciles shifts, and handles purchasing, transfers, and audits.

Goals

  • Reconcile the cash drawer at shift close
  • Reorder and receive stock with less paperwork
  • Run stock audits without closing the shop

Frustrations

  • Manual reconciliation at end of shift
  • Purchase orders and receiving handled on paper
  • Batch and expiry tracking that lives in spreadsheets

Design decisions

Two layouts for two kinds of cashier

The problem. Touch-first shops browse by category and tap; high-volume counters scan and type. One layout can’t serve both without slowing one down.

The decision. A Grid layout for touch and large displays, and a Quick Entry layout tuned for rapid keyboard-driven entry. The business switches in settings, so each shop gets the interface that matches how it sells.

One checkout for retail, wholesale, and credit

The problem. Wholesale and credit customers need different prices and payment terms, and pushing them through the retail flow added steps and mistakes.

The decision. Each line can switch between retail and wholesale pricing, and credit is a payment option in the same confirmation step. The flow stays the same, so all three segments check out faster with nothing extra to learn.

Keyboard-first, mapped to the cashier’s mental model

The problem. Cashiers think ‘scan, total, pay’. Menus that interrupted that order created hesitation and errors.

The decision. One search field handles product name, SKU, and barcode (USB scanner or camera). Enter adds the first match; F-keys cover the rest — F1 search, F2 customer, F9 hold, F8 recall, F10 reprint, F12 checkout.

Interruption-proof sales

The problem. A half-built cart lost to a refresh or a distracted moment meant re-scanning everything.

The decision. Hold and Recall park a sale in one keystroke and persist across page refreshes, with automatic cleanup after 24 hours. Payment supports split tender — cash, card, cheque, and credit — in a single confirmation step.

Hands-free when hands are full

The problem. Cashiers handling products and bags can’t always reach the keyboard.

The decision. Voice commands (‘add two panadol’) add or remove items, with a disambiguation panel when several products match and a spoken confirmation after every action. A separate customer-facing display shows the running basket.

Telegram bot and AI chatbot for owners

The problem. Owners away from the shop had to log in and dig through reports just to answer a simple question, or call the shop instead.

The decision. A Telegram bot and an AI chatbot that give owners the same answers as the dashboard, in a chat they already use every day. Instead of navigating menus, they ask — and the assistant replies with what they need.

  • Sales and business reports on request
  • Financial statements
  • Inventory details and stock levels
  • Purchase order creation, straight from the chat

Support tickets instead of phone calls

The problem. Support happened over phone calls and WhatsApp: hard to track, easy to lose, and interrupting the shop floor.

The decision. An in-app support ticket system where users describe an issue, follow its status, and get answers in one thread. It reduced support calls and WhatsApp contacts by 80%.

Progressive disclosure by role

The problem. Owners need cost prices, margins, and permissions; cashiers need none of it — and seeing it is a risk.

The decision. A permissions matrix with per-business module toggles. Sensitive data such as cost price is hidden from roles without access, so the interface a cashier sees is genuinely simpler.

A calm back office

The problem. Inventory with batches and expiry, purchase orders, transfers, and audits is dense by nature.

The decision. A dashboard for the numbers owners check first, batch selection in first-expired-first-out order, and consistent data tables with search and pagination across all modules.

Results

  • Checkout time — retail customers: −40%
  • Checkout time — wholesale customers: −40%
  • Checkout time — credit customers: −40%
  • Support calls & WhatsApp contacts: −80%

How I measured

Before-and-after comparison reported by the pilot team. It is not an audited A/B test.

  • Checkout time: the time to complete a sale on the previous flow, compared with the same measure during the pilot, reported separately for retail, wholesale and credit customers.
  • Support contacts: phone calls and WhatsApp contacts counted before the support ticket system, compared with the contacts after it was introduced.

Limits of the data

  • Reported by the pilot team, without a control group.
  • Cashiers also got faster with practice, so part of the change may not come from the design alone.
  • Next step: track checkout time and ticket volume inside the product so these become continuous numbers.

My role and process

I led the research and product design: contextual inquiry and task analysis on live retail floors, then flows, prototypes, and the interface system, tested with cashiers before anything was finalised. The design was handed to engineering and refined with them through build, so the checkout behaviour and the owner assistant stayed true to what was tested.

Tools and skills: Figma, Design system, Prototyping, Usability testing, Contextual inquiry

What I'd do next

Track checkout time and support-ticket volume inside the product, so the −40% and −80% results become continuous numbers rather than one-time snapshots.