NafasLand Admin — Store Management & Order Analytics

The store team needed more than product and order lists: daily decisions depend on sales trends, revenue-driving products, repeat customers and bottlenecks in payment and fulfilment. NafasLand is an independent admin panel built around the existing store API, bringing those insights alongside everyday operations. Order reports read from a local SQL Server mirror and expose the latest synchronization time, making data freshness visible. Catalogue, price and stock operations use the portal integration, while sensitive changes follow a separate request-and-approval workflow.

1. 01

   Order analytics and sales KPIs

   Net and gross sales, paid orders, average order value, items per order, discount rate, failed payments and returns are compared with the previous period. Shared filters cover dates, products, variants, status, location, gateway and shipping method.

2. 02

   Monthly progress and sales decomposition

   Persian-calendar monthly progress combines completed-day sales, a month-end projection and configurable sales targets. Sales decomposition separates customer count, orders per customer and average order value, with guest revenue shown independently.

3. 03

   ABC analysis and product performance

   Revenue and cumulative contribution classify products into A, B and C groups. Growth, decline and product return rates help the team investigate catalogue priorities. These revenue measures do not represent product profit.

4. 04

   RFM segmentation and retention cohorts

   New, repeat and guest customers are distinguished. RFM segmentation uses recency, frequency and monetary value to identify groups such as loyal and at-risk customers. Persian-calendar cohorts show repeat purchases, alongside historical customer purchase value and purchase intervals.

5. 05

   Order funnel and operational health

   Registered, paid and fulfilled orders form an operational funnel. Queue age and payment-attempt success by gateway expose potential bottlenecks. A Tehran-time day-and-hour heatmap and province, city and shipping breakdowns reveal operational patterns.

6. 06

   Coupons and market basket analysis

   Orders with and without coupons can be compared. Frequently co-purchased product pairs are reported with support and lift, providing evidence for investigating complementary-product suggestions. Statistical association does not establish causation.

7. 07

   Catalogue and inventory management

   Search and pagination, content and stock status, product creation and editing, rich-text content, categories, filters and metadata support daily catalogue work. Existing product prices and stock are updated through dedicated variant operations.

8. 08

   Permissions, approvals and auditability

   Admin accounts, roles and permissions, organizational access hours, request tracking, approval review, returns and activity logs make team operations controllable. Server-side permission checks and approval workflows guard sensitive changes.

9. 09

   Integration architecture and deployment

   The Next.js and React frontend uses TypeScript, Tailwind CSS and TanStack Query. ASP.NET Core and EF Core on SQL Server support business modules and the local order mirror. Hangfire handles background work; Docker Compose and Caddy provide service orchestration and proxying.

This is an operational system requiring an authorized account. Screenshots show the actual interface with account identifiers and commercial figures redacted. Login credentials and identifiable customer records are not published in this case study.

• Reports read from the local order mirror; synchronization time and reporting cutoff are shown in the panel.
• The month-end projection is an estimate. Reported sales growth is not evidence that this software caused revenue growth.
• Incomplete cohorts and metrics without sufficient data are identified. Historical purchase value is not a prediction of future customer value.