The Problem: Three Teams, Three Versions of the Truth
In a distribution business, an order rarely ends when a salesperson enters it. It moves through several stages before it becomes revenue.
A salesperson takes the order from a customer. The warehouse team needs to pick and pack those items. The accounts team records the transaction in the books. The owner then needs visibility into sales, customers, balances, and business performance.
When each stage depends on a different tool, or worse, paper notes, screenshots, or WhatsApp messages small inefficiencies quickly become operational problems.
Orders can arrive late or incomplete. Warehouse employees may have to work from handwritten notes or screenshots. Sales teams may need to re-enter information. And business owners can end up waiting for an accountant to pull a statement before getting an answer to a simple financial question.
The objective, therefore, was not to introduce more software for the sake of it.
We wanted to make the existing workflow more connected.
That meant keeping Tally as the trusted accounting system while improving the flow of information around it.
How the Three Systems Work Together
The overall workflow is straightforward.
An order starts with the field sales team and moves to the warehouse for fulfillment. The accounting system continues to manage the books, while a separate AI-powered layer makes that data easier for business owners to access and understand.
Each system has a clear role:
- Sales app: Captures customer visits and orders in the field.
- Warehouse workflow: Turns confirmed orders into clear, printable pick
lists. - AI layer: Lets business owners ask questions about accounting data in
plain English.
The important part is not any single system. It is how the information moves between them without creating extra work for the teams using it.
Part 1: A Mobile App Built Around How Field Sales Actually Works
The sales app covers the daily loop of a field team: orders, parties (customers and prospects), visits, and travel. A salesperson opens it, sees who to visit, logs the visit, and places an order on the spot.
Two design choices shaped it. First, speed of entry beats completeness. A salesperson standing in a shop will not fill a long form, so the order flow is built around fast search and repeat items. Second, everything a manager needs is a by-product of normal use. Visits and travel are captured as the team works, so managers get activity visibility without asking anyone to report.
Once an order is confirmed, it becomes the single source for the next two steps: the warehouse and the books.
Part 2: From Order to Pick List in One Click
The warehouse is where order quality turns into delivery quality. Workers do not need a dashboard. They need a clear sheet that tells them what to pick, how much, and for whom.
So we added a print flow that formats a confirmed order into a pick list designed for the shop floor: large, scannable, grouped for picking, and printable on ordinary printers already in the warehouse. No new hardware and no training beyond “print the order.”
This is a small feature with a large effect. It removes retyping, cuts picking mistakes, and gives warehouse staff the same data the salesperson entered, in a form built for their job.
Part 3: An AI Layer That Makes Accounting Data Easier to Use
The accounting side presented a different challenge. The business already relied on Tally for its books, and replacing that system was neither necessary nor desirable.
Tally was trusted. The goal was to build around it.
We therefore built a separate AI-powered layer that connects to Tally, reads relevant accounting information such as statements and balances, and makes that information accessible through a natural-language interface.
Instead of opening Tally or asking someone to prepare a report, an owner can ask a question in plain English the way they would ask an accountant, and get an answer.
Three principles kept it dependable:
- Read-only by design. The layer reads from Tally and never writes back, so
the books stay the source of truth. Separate from the sales app. A problem
in the AI layer cannot affect order taking, and the two can be updated
independently. - Answers come from the data, not from the model’s imagination. Financial
questions need figures that can be traced to a record, so the AI is used to
understand the question and present the result, while the numbers themselves
come from the Tally data itself. - The result is that a question like “what does this customer owe us?” becomes
a quick query instead of a request to another person.
The Decisions Were Based on the Client's Real Needs
Every major choice started from how the client’s business already works. Each one was a deliberate call to deliver the most value within real-world constraints, guided by a client who knew exactly what they needed.
| What the client needed | What we built | Why it works |
|---|---|---|
| Keep Tally as the trusted books | A separate layer that reads from Tally and never writes to it | Accounts stay the single source of truth, and the team adopts it without changing habits |
| Answers owners can rely on | AI that interprets the question, with figures taken from the Tally data itself | Every number traces back to a real record |
| Order taking that never slows down | A sales app that runs independently of the AI layer | Each part updates on its own, so field work is never disrupted |
| A warehouse that runs on what it already has | Print-based pick lists on existing printers | Live from day one, with no new hardware or training |
| Visibility without extra reporting | Visits and travel captured as part of normal use | Managers see activity without asking anyone to report |
What We Learned
The biggest lesson is that integration beats features. None of the three parts is exotic on its own. The value comes from the order flowing from the field to the warehouse to the books without anyone retyping it, and from owners being able to ask questions of that data directly.
The second lesson is to respect the tools people already trust. Building around the existing accounting system, not against it, made the whole project easier to adopt.
The third lesson is about the client. This worked because they came with a clear problem statement, gave us time for detailed discussions, and understood their own business thoroughly. They wanted the best possible setup for their team to work efficiently, while keeping cost as low as possible. That combination pushed us toward simple, proven choices over clever ones, and it is the kind of partnership that produces solid software.
If you run a distribution or trading business and your sales, warehouse, and accounts still live in separate places, we would be glad to talk through what a connected setup could look like for you. You can reach the eLEOPARD team here.
