Order intake and a live sales dashboard for an iPhone business

Orders were written into a notebook first and then posted into Telegram groups. Registering one took about fifteen minutes, some were lost somewhere between the notebook and the group, and entry mistakes were normal. Nobody could state the current state of sales without collecting reports from salespeople and supervisors — reports that sometimes disagreed with each other and could take hours to reach management.

• Only admins the manager had authorised could register an order.
• Every order had to carry the identity of the person who registered it.
• Entry had to be fast and step by step, not one long form.
• The form had to change with the earlier answers rather than ask for everything.
• Data had to be stored in one structured, central place.
• Reporting could not depend on anyone sending a report.
• Management had to see sales without asking for it first.
• The dashboard had to show new information without a manual refresh.

1. Three bots, three responsibilities

   Rather than one bot doing everything, the system is a manager bot that authorises admins by mobile number, an authentication bot that checks whether a number was authorised, and an order bot that only opens for an authenticated admin. Access management, identity and data entry stay three separate things, so changing one of them does not mean touching the other two.

2. Nineteen steps, then one review

   Order entry is a 19-step conversation — supervisor, salesperson, buyer, contact number, model, colour, storage, order code, price, amount paid, plan, payment method, date and time, delivery type, address where it applies, notes. At the end the admin sees the whole order at once and can go back and edit any single step. Nothing is written to the database until that final confirmation.

3. The form is genuinely dynamic

   It is not a fixed list of fields. In-person delivery never asks for an address or a postal code. The chosen iPhone model decides which colours and storage sizes are offered. The purchase plan drives the delivery-time logic. The admin only ever answers what this particular order actually needs.

4. PostgreSQL as the one record

   Orders go into a PostgreSQL schema designed for this business, and each one is linked to the admin who registered it as well as to the customer and the product. That link is what makes the data traceable inside the sales workflow instead of being a pile of independent rows.

5. n8n between the bots and the data

   n8n is the automation layer: it receives what Telegram sends, applies the logic, and writes to PostgreSQL after the final confirmation. That is what turned a manual multi-step routine into one defined flow with a single place to change it.

6. The database becomes a dashboard

   Data that only sits in a database is not visibility, so the system also has its own website and dashboard, connected directly to the data and refreshing every ten seconds. It shows total sales, amounts sold and received, outstanding balances, delivery timing, the nearest upcoming orders, sales per salesperson and per supervisor's team, with charts, filters and time ranges.

• Manager bot that authorises and removes admins by mobile number
• Authentication bot, with access checked against the authorised numbers
• Order bot with a 19-step registration flow
• Full order preview with per-step editing before final submission
• Model-dependent colour and storage options, and plan-dependent delivery logic
• Centralised PostgreSQL storage, every order tied to the admin who registered it
• End-to-end automation of the whole flow in n8n
• A website and dashboard reading the data directly, refreshing every 10 seconds
• Sales and payment reporting, plus per-salesperson and per-supervisor performance
• Filtering, categorisation, sorting, sales charts and time filters