A customer asks for a price in a Facebook comment. Another sends a screenshot of the same product in a message. Someone has paid, but the person packing orders cannot find the delivery address.
If that sounds familiar, your next problem may not be getting more attention. It may be keeping track of the attention you already have.
For a shop in Kathmandu, Pokhara or elsewhere in Nepal, an online store should make the working day easier. Start with a clear order process before deciding how many features the website needs.
Give every order one place to live
Messages are useful for conversations. They are a difficult place to maintain your order book.
Whether you begin with a shared spreadsheet or a small order-management tool, record the same essentials: an order number, product and variant, quantity, agreed total, delivery details and current status. Restrict access to the staff who need it.
Use a few statuses everyone understands: awaiting confirmation, awaiting payment, ready to pack, dispatched and completed. Add cancelled or returned when needed. A colleague should be able to understand an order without reading a whole conversation.
Separate payment received from payment reported
Nepal Rastra Bank publishes indicators covering QR payments, wallets and other payment channels. For your shop, the useful question is which merchant options fit your customers and operating process—not how many payment logos can fit on the page. Source: Nepal Rastra Bank payment indicators
A payment screenshot should not, by itself, move an order to “paid”. Check the provider's merchant records and match the payment to the order. If you add an integration, ask your developer to use the provider's supported server-side verification.
Confirm merchant eligibility, charges, settlement arrangements and integration access with the provider before promising a payment option. A QR image on a page is not the same as an integrated checkout.
Make delivery questions visible before checkout
Write down what you can actually deliver. Do you cover selected areas, or can your delivery partner handle orders outside the valley? Is the delivery charge fixed or dependent on the destination?
Show the answer before a customer commits. If a fee needs confirmation, say so. Ask for a useful address and landmark, without collecting personal details you do not need.
If you offer cash on delivery, include a step for confirming orders and reconciling cash after delivery. Do not assume every courier or location supports the same arrangement.
Keep your first catalogue manageable
Start with products whose prices, variants and stock you can maintain reliably. Use clear photographs, an understandable name, the price in NPR and an explanation of what is included. If availability is uncertain, offer an enquiry instead of an “in stock” promise.
Test the full journey on a phone: find a product, choose a variant, understand delivery, submit an order and receive confirmation. A simple journey that works is more useful than a busy homepage with an unreliable checkout.
What should you build first?
For a small catalogue with frequent custom requests, product pages and structured enquiries may be enough. For standard products with reliable stock and fulfilment, checkout may be the better next step.
Write down your biggest daily problem before choosing a platform. Lost enquiries, stock mismatches and slow payment checks need different solutions.
Where AWKASA can help
Our E-Commerce Solutions for Nepal can help bring product pages, order journeys and integrations into an agreed project scope. We start by mapping what happens now and deciding what belongs in the first version.
If your main issue is keeping customer and order records together, ERP & CRM Applications may be part of that discussion. Provider approval, delivery arrangements and day-to-day order management still need to be agreed before launch.
Bring a few examples of where orders get stuck, with customer details removed. That is a useful starting point for discussing your project.