Narsik Logistics Control Hub: How We Built an OpenAI-Powered PTL Logistics ERP for an Indian Transport Company

A Part Truck Load (PTL) company lives or dies on paperwork. One truck leaving Jaipur at 9 p.m. can carry 30 consignments for 22 customers, each with its own GR number, bilty, freight basis, delivery address and payment term. When a single POD photo goes missing on WhatsApp, a ₹40,000 invoice waits for weeks.

That was daily life at Narsik Logistics. We first built the company an internal ERP in 3.5 months with four developers. Once it was live, we spent six weeks adding an OpenAI layer that now drafts bookings from WhatsApp messages, reads POD photos, matches UPI receipts to open GRs and answers branch managers’ questions in Hinglish.

This article covers the whole build: the business problem, the ERP foundation, the six OpenAI features, the guardrails that keep financial records safe, what it costs to run, and what changed in the 12 weeks after the AI went live. If you are weighing AI SaaS development for an operations-heavy business, this is what it looks like inside a real Indian transport company. The one-page summary lives on the Narsik Logistics ERP case study page.

TL;DR: What this case study shows

• Client: Parmeshwar Kumawat, owner of Narsik Logistics, a multi-branch PTL transport company in India.
• Project: Narsik Logistics Control Hub, an internal logistics ERP with an OpenAI intelligence layer.
• Team and timeline: 4 developers; 3.5 months for the ERP, then a 6-week AI phase.
• AI layer: OpenAI GPT-5.4 mini and GPT-5.4 behind one server-side AI service, using Structured Outputs, vision, tool calling and the Batch API.
• Scale: 4,850 GR bookings and about 4,600 POD images a month across 185 active trips.
• Headline results (12 weeks after AI go-live vs the 12 weeks before): booking entry time down 62% on AI-drafted GRs, POD completion up from 94% to 97.8%, pending customer payments down from ₹18.5 lakh to ₹14.2 lakh.
• Run cost: about ₹11,800 a month in OpenAI usage, roughly ₹2.40 per GR.
• Core lesson: the AI only became useful because the ERP had already put every booking, payment and document behind one API, one permission check and one audit log.

Narsik Logistics Control Hub at a glance

What problem was Narsik Logistics trying to solve?

Narsik’s problem was not a lack of software. It was that shipment records and money records lived in different places, so nobody could see one consignment’s full story without phoning two people.

PTL is harder to run than full truck load. In FTL, one truck means one customer and one invoice. In PTL, one truck carries many customers’ goods, and each consignment moves through booking, loading, branch transfer, delivery and payment on its own clock. A consignment can be delivered while its freight is still unpaid, or paid in advance before it is even loaded.

Indian PTL adds its own layers. Every consignment gets a GR (goods receipt) number and a printed bilty. Freight is charged “Paid” (consignor pays at booking), “To Pay” (consignee pays on delivery) or “TBB” (to be billed on credit). Loads move under a challan. Proof of Delivery is usually a phone photo of a stamped, signed bilty copy sent on WhatsApp.

Seven problems we heard in discovery

The first and last rows shaped everything. Narsik needed one system of record before any AI could help, and branch managers needed answers in the language they actually speak.

Why AI was on the roadmap from day one

Parmeshwar did not ask for AI in the first meeting. He asked why his team still typed the same WhatsApp message into three places. Two of the seven problems are about unstructured input: messy booking messages and phone photos of PODs. Rules and forms cannot read those. A language model with vision can.

So we agreed on two phases. Phase one would build a clean ERP with the data model, permissions and audit trail any AI feature would need. Phase two would add OpenAI where the input is messy and the output can be checked by a person or by code. That order is the main reason the AI phase took six weeks instead of six months.

What did THE TISA build in phase one?

Phase one delivered an internal logistics ERP where every consignment, from booking to POD to final payment, hangs off one GR record. It took 3.5 months with four developers and went live across all branches on the same day.

Four design decisions that later made AI easy

1. The GR is the spine. A confirmed GR stores the booking, the customer charge and the shipment details in one database transaction. Any AI feature that touches a consignment reads and writes through that same GR service, never around it.
2. Money is append-only. A cancelled charge is reversed with a correction entry, never deleted. This later meant an AI-suggested payment allocation could be undone cleanly, with history intact.
3. Branch scope is enforced in the API, not the UI. Every query is filtered by the user’s branches before anything else runs. When we built “Ask Narsik”, the AI inherited that scope for free.
4. Every important action is an audit event. Who did what, when, and from which screen. AI actions slot in as one more actor type: “suggested by AI, approved by Ramesh (Accounts)”.

Why a modular monolith and not microservices?

We chose a NestJS modular monolith on one PostgreSQL database. A GR booking writes to bookings, charges and the ledger at once, and a single database transaction is the simplest way to guarantee they never disagree. Four developers on a 3.5-month timeline also do not need the deployment overhead of a dozen services. Modules are separated by clear boundaries, so the AI service and the ledger can be split out later if load demands it. We explain this trade-off in more depth in microservices vs monolith for AI applications.

Phase-one baseline (the 12 weeks before AI went live)

These are the ERP’s own numbers, which became the baseline we measured the AI against.

The ERP fixed record-keeping. It did not fix the two manual jobs that ate the most hours: typing bookings from messages and chasing PODs and payments. That is where phase two started.

Inside the ERP: how each module works, and what went wrong while we built it

Every module below solved a real PTL problem, and almost every one threw up an engineering problem we did not see coming. We list both, because the second list is where most logistics software projects fail.

1. GR and booking module

What it does. A clerk searches for the consignor (or creates one inline), picks the consignee, origin and destination branches, enters packages, goods description, declared value, actual weight and freight basis (Paid, To Pay or TBB). The rate engine then fills the freight from Narsik’s rate card, adding hamali (loading charges), door collection, door delivery, GR charge and risk charge where they apply. Charged weight is the higher of actual weight and the route’s minimum chargeable weight per package. On save, the ERP issues a GR number, posts the customer charge to the ledger and prints the bilty in three copies: consignor, consignee and office.

Problems we hit during development

• Duplicate GRs from double-clicks. On the slow branch internet, clerks clicked Save twice and got two GRs for one consignment. We added an idempotency key to every booking form submission and a database uniqueness check on it, so a second click returns the first GR instead of creating another.
• The same customer, four times. Narsik’s old registers held “Shree Ganesh Traders”, “Sri Ganesh Trading Co.” and “Shri Ganesh Trd” as separate parties. We added a similarity check using PostgreSQL’s trigram matching that warns before a new customer is created, and a merge tool that moves all GRs and ledger entries to one record with an audit trail.
• Editing a GR after money moved. Clerks needed to fix typos, but changing freight on a GR that was already billed would silently change the ledger. We split GR fields into two groups. Descriptive fields (goods, remarks, consignee contact) can be edited freely and are logged. Financial fields (freight, basis, charged weight) can only change through a correction entry, and a GR already loaded on a challan cannot change destination at all.

2. Trips and challan module

What it does. A dispatcher sees all GRs pending at the branch, grouped by destination route. They pick an owned or hired vehicle and a driver, select GRs, and the ERP checks the load against the vehicle’s capacity in both weight and package count. Saving generates a challan (loading sheet) listing every GR on the truck. Trip expenses such as diesel advance, toll and driver bhatta are recorded against the trip, and for hired trucks the hire amount, advance paid and balance due are recorded against the vendor.

Problems we hit during development

• One GR, two trucks. Two dispatchers at the same branch could select the same pending GR at the same moment and both load it. We moved challan creation into a single database transaction that locks the selected GR rows and re-checks their status before saving. The second dispatcher now gets a clear message naming the GR that was already loaded.
• Split consignments. A 40-carton GR does not always fit on one truck. The first design assumed one GR, one challan, and broke on day two of testing. We redesigned challan lines to carry packages loaded per GR, so a GR can move as 25 cartons today and 15 tomorrow. It shows as “partly dispatched” until every package has left the branch.
• Unknown capacity for hired trucks. Vendor trucks change every trip. Instead of asking the dispatcher to type capacity each time, vehicle records are saved once with their registration, type and capacity, and reused. This was also the fix for the repeated vendor entries listed in the original problem.

3. Shipment status and tracking engine

What it does. Every GR moves through one defined set of states, from booking to POD verification. Each change is stored as a timestamped event with the user and branch, which together form the shipment timeline staff and customers see.

A GR can be cancelled only before it is loaded; after that, problems are handled as held exceptions so the shipment’s history is never lost.

Problems we hit during development

• Statuses set from five different screens. In the first build, booking, challan, arrival and delivery screens each updated the GR’s status field directly, and they disagreed. A GR could show “Delivered” while its challan showed it still in transit. We replaced all of that with one status module. Screens request a transition; the module checks that it is allowed from the current state and for the user’s role, then records it. No other code can write the status.
• Goods arriving short. When a truck reached the destination branch, staff simply marked it arrived. Shortages surfaced only when the customer complained. We added an unloading step that compares packages received against packages loaded on the challan. Any gap puts the GR in a held state with a shortage note before it can go out for delivery.
• Transit branches. Some routes pass through an intermediate branch where goods are unloaded and reloaded. Each transit leg is its own challan, and the GR timeline stitches the legs together, so the customer sees one journey rather than three trucks.
• What customers may see. The public tracking page reads the same timeline but shows only the events, never amounts, internal notes or staff names. Lookups are rate-limited per IP address, and the page is excluded from search indexing.

4. Proof of Delivery module

What it does. Delivery staff or drivers upload a photo of the signed, stamped consignee copy against the GR. The ERP links it to the delivery event and marks the POD as received. Accounts can see every GR delivered without a POD, sorted by age.

Problems we hit during development

• Photos too heavy for highway networks. Phone photos were 3 to 5 MB, and uploads failed on weak 4G. We compress images in the browser before upload to about 250 KB, which keeps stamps and handwriting readable, and retry failed uploads automatically when the connection returns.
• The right photo on the wrong GR. Drivers carrying 20 consignments sometimes attached a POD to the neighbouring GR. Before the AI phase, this was caught only by a manual check in accounts. It later became the first job the POD Reader took over.

5. Customer ledger and payments module

What it does. Every GR charge, receipt, advance, adjustment and correction is a ledger entry against a customer. Receipts can come as cash, UPI, NEFT or cheque, at the booking branch or, for To Pay freight, at the delivery branch. A receipt is allocated to open GRs automatically oldest-first, or manually by accounts. Anything paid beyond the open GRs becomes customer credit. TBB customers get a periodic bill that groups their GRs for the period. Accounts see outstanding balances aged 0 to 30, 31 to 60, 61 to 90 and over 90 days.

Problems we hit during development

• Paise disappearing. An early build stored amounts as JavaScript numbers, and a test bill of 3 GRs at ₹1,234.10 each came out ₹0.01 off. All money now lives in PostgreSQL NUMERIC columns and moves through the code as decimal values, never floating point. A test suite runs 10,000 random allocations and checks every balance to the paisa.
• A balance that drifted. We cached each customer’s balance for fast screens. During load testing, two receipts posted at the same moment produced a wrong cached figure. The cache is now updated in the same transaction as the entry, with a row lock on the customer, and a nightly job recomputes every balance from raw entries and alerts if any cache differs.
• Bounced cheques. A bounced cheque has to undo a receipt that may already be allocated across six GRs. We added a reversal entry that re-opens exactly those allocations, so the GRs show as unpaid again, while the original receipt and the bounce both stay on record.
• Cash collected at the wrong branch. To Pay freight collected in cash at Ahmedabad belongs to a GR booked in Jaipur. We built a branch cash book: delivery staff record cash against the GR, the branch hands it over to head office, and the ledger shows the payment the moment it is collected, while the cash book tracks where the money physically is.

6. Fleet, vendor and trip-cost module

What it does. Owned vehicles carry their documents (registration, insurance, permit, fitness) with expiry dates. Hired vehicles and their owners are stored as vendors with bank and PAN details, used for payouts. Each trip records hire charges, advances, diesel, tolls and driver allowance, so the ERP can show what a trip earned in freight against what it cost.

Problems we hit during development

• Paying vendors before delivery was proven. In the old process, a vendor’s balance was sometimes released while a GR on the truck had no POD, and a later damage claim had nothing to recover against. Vendor settlement is now blocked until every GR on the challan has a POD, unless a manager overrides it, and every override is logged with a reason.
• Trip profit that did not add up. One GR can move on two trucks, and one truck carries 30 GRs. We allocate each trip’s cost to its GRs in proportion to charged weight, which made route-level profit reports possible for the first time.

7. Roles, permissions and branch access

What it does. Eight roles (admin, owner, branch manager, booking clerk, dispatcher, accounts, delivery staff and driver) are mapped to permissions at the level of individual actions, not just screens. A user can belong to several branches. Buttons a user cannot use are hidden, and the API refuses the action even if someone calls it directly.

Problems we hit during development

• Who owns a GR that crosses branches? A Jaipur-to-Ahmedabad GR has to be visible in both branches, and in any transit branch, but its ledger belongs to whichever branch bills it. We separated operational visibility from financial ownership: origin, transit and destination branches see the shipment, while only the billing branch sees and posts its money.
• The head office needs everything, branches need their own. Rather than special-casing head office in every query, branch scope is applied in one data-access layer that every module goes through. An owner simply has all branches assigned. This one layer is also what later kept the AI features inside each user’s scope.

8. Document numbering and printing

What it does. GR, challan and receipt numbers follow a branch and financial-year format, for example JPR/26-27/004518. Bilties and challans print on Narsik’s existing pre-printed stationery. Every print and reprint is logged.

Problems we hit during development

• Duplicate and missing numbers. Generating “last number plus one” in code produced duplicates under load. Each branch and financial year now has its own counter row, incremented inside the same transaction that saves the document, so numbers are unique and gap-free. A cancelled number stays cancelled and is never reused, which Narsik’s auditors required.
• New financial year on 1 April. Sequences restart every April. We tested the rollover with GRs booked at 11:59 p.m. on 31 March and confirmed on 1 April, which uncovered a time-zone bug in the server that we fixed by storing business dates in Indian Standard Time explicitly.
• Printing on old dot-matrix printers. Several branches print bilties on dot-matrix printers using pre-printed forms, and browser printing shifted fields by a few millimetres. We rebuilt the print layouts in millimetre units, calibrated them per branch printer, and stamped every reprint with “DUPLICATE” and the reprint count.

9. Internal chat and notifications

What it does. Staff discuss a shipment inside the GR or trip it concerns, instead of on personal WhatsApp groups. Mentions and key events, such as a shortage at unloading or a failed delivery, trigger in-app notifications.

Problem we hit. Early on, a user could @mention a colleague who had no access to that GR’s branch, which would have shown them the shipment. Mentions are now limited to users who can already see the record.

10. Audit log

What it does. Every important action, including bookings, edits, cancellations, status changes, payments, reversals, prints and permission changes, is written to an append-only audit table with the user, time, branch and before-and-after values.

Problems we hit during development

• Making “permanent” actually permanent. The application’s database role has insert-only rights on the audit table, so not even a bug in our own code can edit or delete history.
• Volume. At around 60,000 events a month, the table would slow down searches within a year. It is partitioned by month, so a search for last week’s changes reads one small partition.

11. Reports and dashboards

What it does. Role-based dashboards show today’s bookings, trips on the road, POD pending, collections and dues at a glance. Standard reports include the booking register, challan register, outstanding ageing, vendor dues, branch-wise collection and trip profitability, all exportable to Excel and PDF.

Problem we hit. Dashboards that summed two years of GRs took over 8 seconds on the first test data. We pre-compute daily summaries per branch every 15 minutes, filter every list by branch and financial year by default, paginate on the server, and index the columns each report filters on. That brought average page load to 1.9 seconds and API response to 320 ms.

12. Data migration and go-live

What it does. Before launch we moved two years of history into the ERP: about 1,16,000 GRs, 640 customers with opening balances, and the active vendor and vehicle lists.

Problems we hit during development

• Messy registers. The Excel files used different column orders per branch, mixed date formats and free-text weights such as “approx 2 qtl”. We wrote branch-specific import scripts, flagged about 3,400 rows that could not be read safely, and had branch staff fix them in a review screen.
• Opening balances that did not match. Customer balances from the registers did not agree with the accounts books for 58 customers. We loaded the accountant-approved balance as a dated opening entry and kept the register history for reference, rather than forcing the two to agree.
• Going live without stopping the trucks. We ran the ERP alongside the old registers for two weeks at the Jaipur branch and compared every day’s bookings and collections. Only after three clean days in a row did the remaining branches switch over.

What OpenAI features did we build into Narsik’s ERP?

We built six OpenAI features, each aimed at a job someone at Narsik was already doing by hand every day. None of them writes to the ledger or changes a shipment status on its own. Every one either drafts something a person approves, or flags something a person checks.

1. Booking Copilot: from WhatsApp message to GR draft

What it does. A clerk pastes a customer’s WhatsApp message, forwards a voice note or uploads a photo of a handwritten slip. The copilot returns a GR draft: consignor, consignee, destination pin code, number of packages, actual and charged weight, goods description, freight basis (Paid, To Pay or TBB) and any special handling note.

A typical input looks like this: “Bhaiya kal Ahmedabad bhejna hai, 14 cartons, approx 380 kg, party Shree Ganesh Traders Naroda, freight to pay.” The copilot fills 11 fields from that line, matches “Shree Ganesh Traders” to the existing consignee record, and leaves the rate for the clerk because rates come from Narsik’s rate card, not from the model.

Why it matters. About 38% of Narsik’s bookings arrive as messages rather than walk-in forms. Typing them took a clerk about 4 minutes 10 seconds per GR. With the copilot, the clerk reviews and confirms in about 1 minute 35 seconds.

How it works. Voice notes are transcribed with gpt-4o-mini-transcribe first. The text then goes to GPT-5.4 mini with a strict JSON schema. Customer names are matched against Narsik’s own customer master using embeddings, so the model never invents a party. Pin codes are validated against a pin-code table, weights are sanity-checked against the package count, and the freight is calculated by the ERP’s rate engine. Any field the model is unsure of comes back as null with a reason, and the form highlights it in amber.

2. POD Reader: checking proof of delivery photos

What it does. When a driver or branch uploads a POD photo, the reader checks it in the background. It extracts the GR number, delivery date and receiver name, and confirms whether a signature and a company stamp are present. It also reads handwritten remarks such as “2 carton damage” or “1 short”.

Why it matters. A POD that is blurry, belongs to a different GR or is missing a stamp used to be discovered weeks later, when a customer disputed the invoice. Now it is caught within minutes, while the driver is still near the delivery point.

How it works. The image goes to GPT-5.4 mini with vision and a schema for the fields above. The ERP then compares the extracted GR number with the GR the photo was uploaded against. If everything matches and no remark is found, the POD is marked verified. A mismatch, a missing stamp or any damage remark sends it to a review queue. Damage and shortage remarks also open a claim draft on the GR. About 81% of PODs are now verified without a person opening them.

3. Payment Match Assistant: allocating UPI and NEFT receipts

What it does. Narsik receives around 2,900 payments a month, many with narrations like “UPI/SHREE GNSH TRD/JPR/4521”. The assistant reads each unallocated receipt and proposes which customer and which open GRs it most likely settles, with a confidence label.

Why does it matters. Unmatched receipts sat in a suspense list while the same customer was being chased for money they had already paid. That is the fastest way to annoy a good customer.

How it works. Embeddings narrow the narration to the five most similar customer names. The model then picks a customer and proposes an allocation across open GRs using amount, date and the customer’s usual payment pattern. The ledger code checks that the allocation adds up to the receipt, never exceeds a GR’s balance, and treats any excess as customer credit. An accountant accepts, edits or rejects. 72% of suggestions are accepted unchanged, and allocation time per receipt fell from about 3 minutes to 50 seconds.

4. Collections Drafts: payment reminders that sound like Narsik

What it does. For each customer with overdue “To Pay” or TBB balances, the assistant drafts a reminder in Hindi or English, listing the exact GRs, delivery dates and amounts, with POD links attached.

Why does it matters. A reminder that lists GR numbers and attaches the POD gets paid. A generic “please clear dues” message gets ignored. Writing the specific version by hand took too long, so it rarely happened.

How it works. All numbers in the message come from the ledger through a template. The model writes only the surrounding sentences, in the tone Narsik sets (polite for first reminders, firmer after 45 days). Accounts review each draft and send it from the ERP. Nothing is sent automatically.

5. Ask Narsik: questions in plain Hinglish

What it does. Branch managers and the owner type questions such as “Jaipur se Ahmedabad ke kitne GR ka POD 2 din se pending hai?” or “Which TBB customers are over 60 days?” and get an answer with a linked list of records.

Why does it matters. Before, every such question meant a call to the head office and someone building a report. Managers now get answers in about 4 seconds.

How it works. The model never writes SQL. It chooses from 14 read-only tools we wrote, such as listPendingPods, getCustomerOutstanding and getTripStatus, and fills in their parameters. Each tool runs with the asking user’s branch scope, so a Jodhpur manager cannot see Surat’s numbers by asking cleverly. The answer is composed only from what the tools returned, and every figure links back to its source records.

6. Daily Exception Digest: what needs attention before 9 a.m.

What it does. Every night, each branch manager gets a short digest: trips running late, PODs pending over 48 hours, damage claims opened, customers crossing their credit limit, and vehicles with documents expiring this month.

Why does it matters. Managers start the day with a list of exceptions instead of scrolling dashboards to find them.

How it works. The ERP computes the exception lists with plain SQL. Overnight, GPT-5.4 mini turns each list into a readable summary through OpenAI’s Batch API, which costs half the price of live calls because nobody needs the digest instantly. Every line keeps a link to its GR or trip.

What OpenAI does, and what Narsik’s own code controls

How does the OpenAI layer fit into the ERP architecture?

OpenAI is one module inside the ERP, not a side system. Every AI request passes the same login, role and branch check as a clerk clicking a button, and every AI result goes back through the same business modules before anything touches the database.

The AI service hands its drafts to the business modules for validation; it never writes to PostgreSQL directly. Slow jobs such as POD reads and the nightly digest run through the queue so the ERP screens stay fast. POD photos and printed PDFs live in object storage and are served only through short-lived signed URLs.

From WhatsApp message to confirmed GR, step by step

1. Request. A signed-in clerk pastes a message or uploads a voice note in the booking screen.
2. Authorise and scope. The API checks the clerk’s role and branches, then loads only what the job needs: the clerk’s branch, its routes and the top customer-name candidates.
3. Redact. Phone numbers and GSTINs in the message are replaced with placeholders before the call, and restored after. The model does not need them to read a booking.
4. Structured generation. The AI service calls OpenAI with a fixed JSON schema using Structured Outputs, so the response always has the same shape.
5. Validate in code. The GR module checks the pin code, matches the customer ID, checks weight against package count, and calculates freight from the rate card.
6. Human review. The draft opens in the normal GR form with uncertain fields in amber. The clerk edits and confirms.
7. Commit and log. The GR is saved through the same transaction as a manual booking, with an audit entry: “drafted by AI, confirmed by Sunita (Booking, Jaipur)”.

A simplified version of the generation step:

// booking-copilot.service.ts (simplified, server-side only)
const scoped = await this.context.forBooking(user);          // branch-scoped data only
const input  = this.redactor.mask(rawMessage);               // phones, GSTINs masked

const res = await this.openai.responses.create({
  model: this.config.models.extraction,                      // gpt-5.4-mini
  input: buildBookingPrompt(input.text, scoped),
  text: { format: { type: 'json_schema', name: 'gr_draft',
                    schema: grDraftSchema, strict: true } },
}, { timeout: 15_000, maxRetries: 1 });

const draft   = this.redactor.unmask(JSON.parse(res.output_text), input.map);
const checked = await this.grRules.validate(draft, user);   // pin, party, weight, rate
await this.audit.log('ai.gr_draft', { user, usage: res.usage, flags: checked.flags });
return checked;                                              // a draft, not a GR

Guardrails we built in

• Server-side keys. OpenAI is called only from the NestJS server. Keys live in the cloud secret manager and never reach the browser or the driver app.
• Drafts, never writes. The AI service returns proposals. Only the business modules create GRs, post ledger entries or change statuses, and only after a person confirms.
• Branch scope before context. Data is filtered by the user’s branches before it is put into a prompt, so the model cannot leak what it was never sent.
• Read-only tools for Ask Narsik. Fourteen typed functions, each with its own branch filter and row limit. No free-form SQL, no write tools.
• Numbers come from code. Freight, balances, allocations and reminder amounts are calculated by the ERP. The model writes words around them.
• Timeouts and fallbacks. Each call has a 15-second timeout and one retry. If OpenAI is slow or down, the normal manual form simply opens empty. Bookings never stop.
• Idempotency. Each AI job carries a key tied to the GR or receipt, so a retry never creates a duplicate draft.
• Cost and usage logging. Every call records feature, model, tokens and latency, so cost per GR can be tracked monthly.

What leaves Narsik’s system, and what does not

We send OpenAI only the fields a feature needs: the booking message text, a POD image, a receipt narration with candidate customer names, or a pre-computed exception list. We do not send bank account details, full ledgers, other branches’ data or anything a user could not already see.

According to OpenAI’s data controls documentation, API data is not used to train models unless the customer opts in, and abuse-monitoring logs are kept for up to 30 days. Narsik’s account uses the default API settings. Because the OpenAI calls sit behind one internal service, switching models or providers later does not mean rewriting features, a point we cover in our vendor-agnostic AI guide.

Developer’s perspective: making AI safe around money

Anuj Kumawat, AI/ML Engineer, THE TISA

“Reading a Hinglish booking message was the easy part. The hard part was making sure a confident-looking wrong answer could never become a wrong invoice. So we drew a hard line. The model can propose a customer, a weight or an allocation, but the ERP decides whether it is valid. If the model is unsure, it has to say null, and the form makes that visible. Clerks trusted the copilot faster once they saw it admit what it did not know.”

Nishant Agarwal, Full Stack Developer, THE TISA

“Because the ERP already had one GR service, one ledger service and one audit log, the AI phase was mostly wiring, not rebuilding. The AI draft goes through exactly the same validation as a clerk’s typing. That is why we could ship six features in six weeks without touching the ledger logic.”

How did we test the AI before it touched real bookings?

We built a test set from Narsik’s own history before writing a single prompt, and no feature went live until it beat a pass mark on that set. Generic benchmarks say little about whether a model can read “14 ctn 380kg to pay Naroda”.

The most important row is the 0.8%. A POD marked verified when it should not be is the one error that can cost money, so we tuned the reader to send anything doubtful to a person. We rerun the full test set before every prompt or model change, and track the same measures weekly from production corrections.

What does the OpenAI layer cost to run?

Narsik’s OpenAI bill averages about ₹11,800 a month (roughly $140), or ₹2.43 per GR booked. That is less than the cost of one clerk-hour a day.

Three choices kept the bill low. The small model handles every high-volume job; the larger model is used only where it has to reason across several tool calls. The nightly digest runs through the Batch API at half price. And the fixed instructions at the start of each prompt are kept identical between calls, so OpenAI’s prompt caching cuts the cost of repeated input. For a wider view of what drives these numbers, see our AI SaaS development cost guide.

What results did the OpenAI integration deliver?

In the 12 weeks after the AI went live, compared with the 12 weeks before, Narsik’s team spent far less time typing and chasing, and money came in faster. Volumes stayed roughly flat across both periods, at about 4,850 GRs a month.

How these metrics were measured and verified

Every figure above comes from system records, not surveys. Both windows are 12 weeks long, with similar booking volumes.

Adding up booking, POD review and receipt allocation, the team saves about 190 staff-hours a month, a little over one full-time clerk. Nobody was let go. Booking clerks now spend that time calling customers about pending pickups, and accounts spend it on GST reconciliation that used to slip to month-end.

What these numbers do not prove

• Dispatch and on-time gains are only partly AI. Faster bookings help dispatch, but Narsik also reorganised the loading bays at two branches during the same period. We credit the AI with the direction, not the full size, of those two rows.
• Collections improved for two reasons. Faster POD verification and specific reminders both helped, and we cannot cleanly separate them.
• Twelve weeks is a short window. We will republish these figures after a full year, including the festive peak.

What changed for each team

What the client said

“Our team was facing difficulty in managing shipment and payment records through separate processes. The TISA team understood the problem and built a practical platform that brought the main work together. The system is reliable and easy for our employees to use.” Parmeshwar Kumawat, Owner, Narsik Logistics

Narsik Logistics operates at narsiklogistics.com. This testimonial is also published, with the client’s attribution, on the Narsik Logistics ERP case study page.

How long did the AI phase take?

The OpenAI layer took six weeks with two of the original four developers, following the stages in our AI software development process. It was short because the ERP had already done the heavy lifting.

1. Week 1: Use-case selection and test sets. We shadowed booking clerks and accounts for two days, ranked 11 candidate ideas by hours saved and risk, and kept six. We labelled the 1,200-message, 600-POD and 900-receipt test sets.
2. Week 2: AI service and guardrails. One NestJS module for all OpenAI calls: schemas, redaction, timeouts, idempotency keys, cost logging and audit events.
3. Weeks 3 and 4: Booking Copilot, POD Reader and Payment Match. The three highest-volume features, each tested against its set before any UI work.
4. Week 5: Ask Narsik, Collections Drafts and Exception Digest. The 14 read-only tools, the reminder templates and the nightly batch job.
5. Week 6: Pilot and rollout. One week live at the Jaipur branch only, with every AI draft compared against what the clerk finally saved. Prompts were tuned on 214 corrections, then all branches went live.

What should logistics and SaaS founders learn from Narsik?

The main lesson: build the system of record first, then add AI where the input is messy and the output can be checked. These six lessons apply well beyond trucking.

1. Start with the job people hate, not the demo that impresses. Retyping WhatsApp bookings was nobody’s favourite task. It became the most-used feature.
2. Let the model read, let code decide. Freight, balances and permissions have right answers. Keep them in code you can test.
3. Make “I don’t know” a valid answer. A schema that allows null with a reason made the copilot trustworthy faster than any accuracy number.
4. Build the test set before the prompt. Real messages, real photos, real receipts. It is the only way to know if a change made things better.
5. Append-only money makes AI reversible. Because ledger corrections are new entries, an AI-suggested allocation that turns out wrong is undone in one click, with history intact.
6. Measure the baseline before launch. We could only report a 62% drop in booking time because we timed it beforehand.

Should you build a custom AI logistics ERP or buy one?

Buy if your workflow is standard; build if your workflow is your edge or your product. Narsik built because its PTL rules, Hinglish bookings and branch structure did not fit off-the-shelf transport software without heavy workarounds.

If you are a logistics operator thinking of turning your internal system into a product for other transporters, the same architecture is the starting point for a multi-tenant AI-powered SaaS platform.

Is your operation ready for an AI layer?

• ☐ Every booking, payment and document goes through one system, not three
• ☐ Permissions are checked on the server, by role and branch
• ☐ Money records are append-only, with corrections as new entries
• ☐ Important actions are logged with who, what and when
• ☐ You can name the one manual job AI should take on first
• ☐ You have measured how long that job takes today
• ☐ You know which data may and may not leave your system
• ☐ Someone will own AI quality after launch

Fewer than five tickets? Start with the system of record, as Narsik did, and let our AI workflow automation team map the AI opportunities in parallel.

What’s next for Narsik Logistics Control Hub?

These are planned, not shipped:

• WhatsApp Business integration, so the Booking Copilot reads messages directly and sends GR confirmations back, through our AI integration services
• Delay prediction from trip history, route and weather, flagging likely late GRs before dispatch
• E-way bill and GST automation, including e-invoice generation for TBB customers
• A customer self-service agent that answers “where is my shipment?” on WhatsApp, built with AI agent development
• Search across chat history and claims using RAG development, so a manager can ask what was agreed with a customer last month
• Live GPS and driver mobile app, replacing manual branch movement updates

How does THE TISA take an AI SaaS product from idea to production?

We take an AI SaaS product through seven stages, and the AI comes after the data, permissions and core workflows are solid. Narsik followed exactly this path; the right-hand column shows what each stage looked like there.

Typical starting points and timelines

Narsik sat between small business and mid-market: a multi-branch operation that needed a full system of record before any AI.

THE TISA delivery capabilities

Frequently asked questions

Q1. How long does it take to build a logistics ERP with AI?
Ans. Narsik’s ERP took 3.5 months with four developers, and the OpenAI layer took another six weeks with two of them. A smaller transporter with one or two branches could start with a narrower scope. More branches, integrations such as e-way bills, or a customer app extend the timeline.

Q2. Can AI be added to an existing logistics or transport system?
Ans. Yes, if the system has an API, server-side permissions and clean records. If bookings and payments still live in spreadsheets, building a proper system of record first is usually faster and safer than putting AI on top of scattered data.

Q3. Which OpenAI models does Narsik use, and why?
Ans. GPT-5.4 mini handles high-volume work: booking extraction, POD photo reading, payment matching and reminder drafts. GPT-5.4 runs Ask Narsik, where it must choose between several tools. All calls go through one internal service, so models can be swapped without rewriting features.

Q4. How does AI read proof of delivery photos?
Ans. The POD Reader sends the photo to a vision-capable model with a fixed schema. It returns the GR number, date, receiver, whether a stamp and signature are present, and any handwritten remarks. The ERP then checks the GR number against the shipment and sends anything doubtful to a person.

Q5. Can the AI change bills, payments or shipment status on its own?
Ans. No. Every AI feature returns a draft or a flag. GRs, ledger entries and status changes are created only by the ERP’s business modules, after a person confirms. Every AI-assisted action is logged as “suggested by AI, approved by” a named user.

Q6. Does Narsik’s data go to OpenAI, and is it used for training?
Ans. Only the fields a feature needs are sent, after phone numbers and GSTINs are masked. Bank details and full ledgers are never sent. OpenAI’s documentation states that API data is not used for training unless the customer opts in, and abuse-monitoring logs are kept for up to 30 days.

Q7. Can it understand Hindi and Hinglish booking messages?
Ans. Yes. About half of Narsik’s message bookings mix Hindi and English, and many arrive as voice notes. Voice notes are transcribed first, then extracted. On a test set of 1,200 real messages, 96.4% of fields were correct after the ERP’s own validation.

Q8. How much does an OpenAI integration cost to run for a transport company?
Ans. Narsik spends about ₹11,800 a month, or ₹2.43 per GR, for roughly 4,850 GRs. Cost depends mostly on how many images you process and how often the larger model is used. Batch processing and prompt caching keep routine jobs cheap.

Q9. Why a modular monolith instead of microservices?
Ans. A GR booking writes to bookings, charges and the ledger at once, and one database transaction is the simplest way to keep them consistent. With four developers and a short timeline, one deployable app was also easier to run. Modules can be split out later if load requires it.

Q10. Can this ERP become a SaaS product for other transporters?
Ans. Yes. The data model is already branch-scoped, so adding a tenant layer above branches is a contained change. Billing, tenant onboarding and per-tenant AI cost limits would be the main additions.

Planning AI for your logistics or operations software?

If your team still retypes messages, chases photos and matches payments by memory, the first step is the one Narsik took: a short review of your workflows, data and permissions. That review tells you which AI feature to ship first, what it will cost to run, and what it will save.

THE TISA is an AI SaaS development company that builds production AI into the systems businesses run on. Explore our logistics and supply chain work, read how we handle security, or browse more AI software development case studies, including the Clove OpenAI project management SaaS and OpsPilot.