Packaging manufacturing — an operating case study
The problem · the process · the outcome
Biz Systems · Zoho Advanced Partner
Client not named · stack named · figures real
Client not named · stack named · figures real
A packaging manufacturer with three plants, three warehouses and sixty-odd people. It makes most of what it sells, buys the rest from a factory it part-owns, and sells through its own website, two online marketplaces and a field sales team. Two systems were already bought, set up and running — Zoho CRM for sales, Zoho ERP for orders, stock and the accounts. Nobody trusted the numbers coming out of either, including the people producing them. This is what we found, what we built, and what changed.
The company earns money in three different ways at the same time, and a customer is not supposed to be able to tell which one they got.
| Route | How the goods come to exist | Who is involved |
|---|---|---|
| Own manufacture | Made in the company's own plants, to order or to stock | Three plants, own staff, own quality checks |
| Partner manufacture | Made to the company's specification by a factory it part-owns | Ordered like a vendor; sold under the company's own name |
| Trading | Bought in and shipped straight from the vendor to the customer | The customer never deals with the vendor |
Orders arrive through the field sales team, through the company's own website, and through two online marketplaces. That is three ways of making the goods and four ways of taking the order — twelve combinations, running through one set of people.
Both systems were live before we arrived. Zoho CRM held enquiries and deals. The other system held orders, stock, purchases and the accounts. The problem was never that the company had no software. It was that the software had been set up and never designed — and that nobody had ever written down, in one sentence, how the business was supposed to work.
"It's a sales performance problem." The headline number said 594 enquiries had produced 17 orders. Every person in the room read that the same way: the team is not trying hard enough. The obvious next step was to push them.
"The staff aren't using the system properly." Records were half-filled, so the conclusion was that people were careless. They were not. They were filling in what the system asked for and keeping the work that actually mattered somewhere else.
"We need better software." This is the most expensive belief of the three, because acting on it costs money and changes nothing. Neither system was at fault. Both were faithfully recording a business that had never agreed with itself.
None of this came from a workshop or an opinion survey. We read both systems directly and counted. The table below is the full list, grouped by the part of the business it sits in. Nothing here is unusual — we find most of it in most companies of this size. What is unusual is seeing it all written down at once.
| What we found | What it meant day to day | Fixed in |
|---|---|---|
| 1 · Sales — the process itself | ||
| Two official process documents, and they disagreed | Both were in use. They gave different answers to one question: when does a sale count as won? That single answer decides the conversion rate, the forecast, the month a salesperson gets paid for, and the moment a job stops being sales and becomes production. With two answers, every one of those had two versions and both could be defended. | 2.3 |
| Six pipelines running side by side | One for each of four enquiry sources and each of two customer types. The same sale could be run four different ways. Nothing could be compared with anything else, so no trend meant anything. | 2.3 |
| Stages that asked for nothing | The system controlled the order of the stages but never required a single fact before letting a deal move forward. A deal could travel the whole pipeline without leaving any record of why. The sequence was controlled; the evidence was not. | 2.2 · 2.3 |
| 594 enquiries, 17 orders | Not a measurement. Whichever of the two definitions the person writing the report happened to use produced a different answer, so the number changed depending on who compiled it. | 2.3 |
| 973 deals on a private list, 11 in the official one | People kept their real work outside the system, because the system asked for the wrong things and gave nothing useful back. Everybody could see this was happening. Nobody could see the list. | 2.3 |
| 2 · Sales — who did what, and where enquiries came from | ||
| Live chat on the website was an island | A serious enquiry from the website chat never became a record. It became a phone call, and then a quote. So the enquiry existed nowhere: no source, no owner, no stage, no proof it had ever happened. One of the better sources of business in the company was invisible in every report. | 2.2 · 2.3 |
| Two calls logged in total | The team was on the phone all day. What did not exist was any record of it that survived the person who made the call. If that person was ill, on leave, or left, the relationship left with them. | 2.3 |
| Nobody could say who handled how much | Enquiries, quotes and invoices could not be traced to a person. So individual performance could not be measured, and was managed on impression instead — who looks busy, who sounds confident. That is unfair to the quiet, effective people, and it is usually how they end up leaving. | 2.3 · 2.11 |
| No rule said which enquiry went to whom | Export, bulk, small-ticket and repeat enquiries all landed wherever they landed. The person best placed to close a particular enquiry very often never saw it. | 2.2 |
| 3 · Price, discount and credit | ||
| Three-quarters of the products had no price | 1,234 items out of 1,618 carried no selling price, and not one carried its cost next to its selling price. Quotes were built from a handwritten rate sheet, or by ringing the owner on smaller deals. At the exact moment a number was promised to a customer, nobody in the building knew the margin on it. | 2.3 · 2.6 |
| Discount and credit rules existed only on paper | A salesperson could not give credit and could not discount beyond 2%. But approval was verbal, deal by deal. Nothing recorded what was asked for, what was given, or why — and nothing checked whether a price had quietly gone below the floor to win the order. | 2.3 · 2.4 |
| 4 · Taking orders from the website | ||
| 200 orders a day, 600 bills typed by hand | The website took around 200 orders a day and was connected to nothing. Each order was billed by hand in a spreadsheet, in three copies — customer copy, office copy, transporter copy. All 600 were emailed, printed and sent out with the goods. The day's orders were then typed into the main system once a week. For six days out of seven, the accounts, the stock and the debtor list described a company that no longer existed. | 2.5 · 2.12 |
| 5 · Service — everything after the sale | ||
| Customers had no way to look anything up | There was no customer login. A customer could not see their past orders, their bills, their payments, or where a live order had reached. So every one of those questions became a phone call, a message or an email — and had to be answered by a person. | 2.4 · 2.9 |
| Questions arrived as loose text | A customer asking about an order typed or read out an order number into a message. Nothing joined the question to the order, so whoever answered had to go and find it first. And afterwards, nothing recorded that the order had ever been asked about. | 2.9 |
| Complaints were never linked to products or orders | Because no question was attached to an order or an item, nobody could say which products or which orders caused the most trouble. The single most useful piece of information about what to fix in the factory was being produced every day and thrown away. | 2.9 · 2.7 |
| 6 · The two systems, and the data inside them | ||
| The two systems were not connected | Customers, contacts and products were maintained twice, separately. Neither system could answer who is this customer, what have they bought, and what do they owe us without a person comparing the two by hand — and the two never quite matched. | 2.5 · 2.12 |
| The accounts system had duplicates of its own | The same buyer existed several times over inside it, so their ledger, their ageing and their turnover were split across copies. There was no clean side to copy from. | 2.2 · 2.5 |
| 13,266 companies on file, 2 named people | A complete record of who they had sold to, and almost no record of a single human being to ring. Companies do not answer the phone. People do. | 2.2 |
| The product list could not be added up | Three separate fields competed to say what a product was. The field called "category" actually held a specification, typed in freely — 57 different values for a handful of real ones, and 730 items with nothing at all. About five real units of measure were spelled thirteen ways. Not one item in 1,618 had a reorder level, which makes a low-stock warning arithmetically impossible. | 2.6 |
| 7 · The books underneath | ||
| The opening balances had never been signed off | The move from the old accounting package had been done, but the chart of accounts, the trial balance and the stock balance had not been reconciled and signed by the accountant. So the system was keeping a careful record starting from a position nobody had agreed. | 2.13 |
It is worth being precise about the cause, because the wrong diagnosis leads to the wrong spend.
It is not a people problem. The sales team was working flat out. The accounts team was producing 600 documents a day by hand, on time, every day, without complaint. That is not a team that needs pushing.
It is not a software problem. Both systems were capable of everything described in Part Two. They were doing exactly what they had been told to do.
It is a shape problem. Four questions had never been answered in one agreed sentence:
Until those are answered, no system can record them. What gets built instead is a careful, permanent record of the disagreement — and then everybody blames the record.
1 · You cannot manage what you cannot compare. Two definitions of a won deal mean two conversion rates, both defensible. So the same argument reappears in every review meeting, for years, and is never settled.
2 · Effort gets absorbed. A push produces visible movement within a week, which is exactly why it is so convincing. But a team running at full effort through a process that contradicts itself arrives at the same place, tired.
3 · It compounds. While we were reading, 4,667 new duplicate accounts were created, because the duplicate check was switched off. Every month of growth adds records in the old pattern and raises the eventual cost of fixing it.
The client is not named in this document. The software is — because the question every owner asks at this point is "what does it actually take to run like this", and the honest answer is a named list rather than a vague one. Nothing here is exotic. It is one vendor's suite, configured to a process that was agreed first.
| Product | What it owns in this design | Where to see it |
|---|---|---|
| Zoho CRM | Both pipelines, the sixteen required fields, the duplicate check, follow-up and escalation rules, the discount matrix, the repeat-business clocks and the review request | 2.2 · 2.3 · 2.4 |
| Zoho ERP | The order record, credit and stock checks, the item master, manufacturing and quality, purchasing, warehouses, invoicing, collections, the ledger, payroll and both portals | 2.5 – 2.8 |
| Zoho Desk | Tickets tied to an account and an order, the clock by complaint type, escalation on breach, the rating at closure | 2.9 |
| Zoho SalesIQ | Website chat with visitor context, routed to sales or to service — the channel that used to reach neither system | 2.2 |
| Zoho Commerce | The D2C website and the B2B customer portal: catalogue, customer-specific prices, self-ordering, order history, invoices and delivery proofs | 2.5 · 2.9 |
| Zoho Payments | Checkout, payment links on invoices, and the single feed every receipt lands in | 2.5 |
| Zoho Analytics | The Monday report that compiles itself on Sunday night, and a dashboard per role | 2.11 |
| Zoho Forms | The website enquiry form into CRM and the complaint form into Desk, each with its own acknowledgement | 2.2 |
| Zoho Flow | Paid-ad leads and spreadsheet lists into CRM, de-duplicated on the way in | 2.2 |
| Zoho Recruit | The recruiting system of record — candidates, job openings, departments and interviews. Four modules stay in step with the hiring app built on top of it | 2.10 |
| Zoho People | The employee from day one: record, documents, leave, self-service and exit | 2.10 |
| Zoho Catalyst | The two pieces we had to build: the service linking CRM and ERP, because no ready-made link between those two exists — and the hiring app that runs the five-round funnel on top of Recruit | 2.3 · 2.10 |
| Attendance app | Geo-checked attendance at all four sites, feeding the locked month into payroll | 2.10 |
What follows is the operating model we designed and built, in the order a piece of work actually travels through the company. Each chapter shows the flow as a diagram, then the detail underneath it: the steps, the rules, the numbers that are checked, and the one or two control points that decide whether the rest of it works. Read the diagrams first. Solid arrows are people moving the work. Dashed arrows are the systems moving it, with nobody re-typing anything. Red boxes are the points where the whole thing either holds or breaks.
Before the detail, the shape. Exhibit 1 is the entire business on a single page: an order arrives through one of the front doors, is won in Zoho CRM, made and shipped by the order-and-stock system, paid for, and then looked after — with hiring and pay running underneath, and one weekly report reading the lot.
Two boxes are marked in red, and they carry the whole map. The sales order is where a won deal becomes a real commitment without anyone typing it again. The stock check is where the business decides whether to ship what it has or make something new. Everything downstream inherits whatever those two get wrong.
Nine ways in, one record, one agreed definition of a won sale. Chapters 2.2 – 2.4.
The same order changing hands until the money is reconciled. Chapters 2.5 – 2.8.
Service after delivery, and the people machinery underneath. Chapters 2.9 – 2.12.
Enquiries reached the company through nine different routes. Each was answered by a different person and written down differently, or not at all. The design rule is simple: whichever door an enquiry uses, it ends up as the same record — tagged with where it came from, checked against the customers we already have, routed to the right pipeline, given an owner, and put on a clock. All of that happens before the first phone call.
| Where it comes from | How it reaches Zoho CRM |
|---|---|
| Trade portal — account 1 | Direct feed, with its own tag so the two accounts can be compared |
| Trade portal — account 2 | Separate feed, separate tag |
| Paid social advertising | Connector creates the record automatically |
| Zoho Forms — enquiry | Creates the record and sends the customer an acknowledgement |
| Spreadsheet lists — trade shows, old databases | Connector adds new rows; skips anything whose phone number is already on file |
| Zoho SalesIQ | Record created as soon as the visitor shares a contact; an after-hours chat becomes a record next morning |
| Messages, walk-ins, referrals | Typed in by hand — but the required fields stop the record being saved half-empty |
| Cold calls | Typed in by the salesperson, same rules |
| Zoho Forms — complaint | Goes to Zoho Desk instead, as a ticket (Exhibit 8) |
New business runs three tracks inside one pipeline: a new customer, a large target account, and export. Exhibit 3 shows the new-customer track, which carries the volume. The two decisions that matter most here cannot be seen on any screen: what "won" means (the advance is in and the order is raised) and who may discount, and by how much. A third is worth stating because it is so often built the other way — a deal never changes pipeline once it exists. That was decided when the record was created, and it stays decided.
| # | Step | What happens | Day |
|---|---|---|---|
| 1 | Enquiry saved | Source, product, quantity, city and type of business recorded; owner assigned | 0 |
| 2 | First call | Within 24 hours. Qualify the need, the quantity and who supplies them now. Notes logged. | 1 |
| 3 | Quote and sample | Quote built on real prices; sample sent; a 48-hour follow-up task created automatically; customer told when the sample ships | 2–4 |
| 4 | Three follow-ups | Day 5 sample feedback · Day 8 price · Day 12 decision. Every call logged. | 5–12 |
| 5 | Negotiation | Price, payment terms, delivery promise. Anything beyond the standard discount needs approval. | 7–14 |
| 6 | Order won | Advance received; the order is created in the other system automatically; feedback taken after delivery | 14–21 |
| 7 | Where they go next | The deal ends here and stays in new business. What changed is the account — it now has order history. So their next enquiry is saved straight into repeat business by the same check. | next enquiry |
| Discount | Who approves it | On what condition |
|---|---|---|
| up to 3% | The salesperson | Reason recorded on the deal |
| 3–7% | Sales manager | Reason, customer profile and the competitive situation recorded |
| 7–12% | A director | Target accounts, large orders, tenders |
| above 12% | Both directors and the accounts head | Strategic accounts and large tenders only |
Before this, the rule was 2% and the approval was a phone call. The new ceiling is slightly higher and, for the first time, actually enforced — and every approval leaves a record of what was asked for and why.
| Large target accounts (weeks) | Export (days) |
|---|---|
| 1 Identify — research the company, the decision maker, what they spend, who supplies them now | 1 Enquiry logged — country, buyer, specification, quantity, shipping terms, timeline |
| 2 Approach — introduction, catalogue, get a meeting | 2 Quote — with tariff codes, duties and any certificates |
| 3 Present — samples, examples, the cost case | 3 Sample and documents sent |
| 4 Custom proposal — special pricing, terms and delivery promise in writing | 4 Negotiation — payment method, minimum order, guidance from the accountant |
| 5 Nurture monthly — never pressure | 5 Order — production order, freight forwarder, shipping documents (day 21+) |
| 6 Won — special onboarding; from their next enquiry they are a repeat account |
Repeat business is where most of the margin lives, and before this it was nobody's job. New business always has a name against it and a target riding on it. The second order usually has neither — it is assumed. It happens because the customer remembers you, and it stops happening quietly for the same reason.
An account arrives here the same way every record arrives anywhere in this design: when an enquiry is saved and the system sees it has order history. From then on, two facts drive everything — when they last ordered, and how much they usually order. The salesperson's job becomes ringing the right people on the right day. Nothing has to be remembered.
| Stage | What triggers it | What happens |
|---|---|---|
| Active | Every order | Quality, on-time delivery, a monthly relationship call |
| Reorder reminder | 30 days after the last order | Automatic message to the customer, and a call task to the owner |
| Upsell | Quarterly | Pitch the products that naturally sit alongside what they already buy |
| At risk | 60 days silent | Flagged automatically, the manager is told, and somebody calls. The reason is recorded: price, quality or competitor. |
| Lost | 90 days, three attempts | Marked lost — never deleted. Re-approached in three months. |
| Loyal | Two years of clean payment | Credit facility, priority despatch |
| Stage | Trigger | Treatment |
|---|---|---|
| Identified | Volume up 20% in a quarter, or one large order | Special handling switched on automatically |
| Priority | Always | A dedicated contact, same-day response, priority in the production queue |
| Annual deal | Quarterly review | Contract, volume slabs, custom product if needed |
| Strategic | Half-yearly | Exclusive supply, joint planning of capacity |
| Customer | Limit | Days | Who approves |
|---|---|---|---|
| New — first three months | None, advance only | 0 | — |
| Regular, clean payment | Small | 30 | Sales manager |
| Established, 1–3 years | Medium | 45 | Sales manager + accounts head; added to the credit-insurance list |
| Long-standing key account | Large | 60 | Director; insurance cover compulsory |
| Export | Per the payment instrument | contract | Director, with the accountant |
| Marketplace orders | The platform pays | 7–14 | — |
Reviewed every six months. Two late payments halve the limit. Ninety days outstanding suspends credit.
Every business customer gets their own login, showing only their products at their own agreed prices: order history, live status of anything in progress, invoices, payments, delivery proofs, one-click reorder, and a complaint raised against a specific order. The target is a sharp drop in the time the sales team spends taking orders, and no more "where is my order" calls at all.
Whether an order comes from a won deal, a customer ordering on their own portal, a website checkout or a marketplace feed, it becomes the same order record and follows the same chain: credit check, stock check, picking and packing, despatch checklist, tax invoice, payment, bank reconciliation twice a day, receipt applied. The customer is told four times along the way — confirmed, despatched with a tracking link, invoiced, delivered — and nobody types any of those messages.
| Step | Who or what does it | The control |
|---|---|---|
| Order created | Automatic, from Zoho CRM, the portal, the website or a marketplace | Only a won deal or a paid checkout can create one |
| Credit check | Against the credit policy in 2.4 | New customer means advance only; limits and terms set by history |
| Stock check | Across all three warehouses, with transfers between them if needed | In stock, it ships. Not in stock, it becomes a production order or a purchase order. |
| Picking and packing | Warehouse team, from a picklist; the right label format for the channel | Marketplace orders out within 24 hours |
| Despatch checklist | Despatch team: courier, tracking number, weight | The order cannot be closed without proof of delivery |
| Tax invoice | Raised automatically by the despatch, with tax numbers, product codes and the tax split | Every invoice is system-generated. There are no hand-made ones. |
| Payment | Online at checkout, a payment link on the invoice, a bank transfer, or a marketplace settlement | Every receipt lands in one bank feed |
| Bank reconciliation | Twice a day, 9 AM and 6 PM: statement imported, matched, mismatches flagged | Zero difference at both checks |
| Receipt applied | Invoice cleared, ageing updated, status written back onto the customer record | The salesperson can see who has paid without asking accounts |
| Overdue | What happens | Who does it |
|---|---|---|
| Invoice date | Invoice and message sent; the payment clock starts | Automatic |
| Due date | "Payment due today" reminder | Automatic |
| Day 7 | Friendly call, outcome recorded | Salesperson |
| Day 15 | Accounts call; new orders put on hold | Accounts |
| Day 30 | Personal call; payment plan if there is genuine hardship | Sales manager |
| Day 45 | Director calls on large balances; formal letter | Director + accounts |
| Day 60 | Final notice; the credit insurer is informed | Accounts |
| Day 90 | Handed to a lawyer; written off in the books; insurance claim filed | Legal + accounts |
The stock check in 2.5, the consumption figures in 2.7 and the margin-by-product line in the weekly report all read from one place: the product list. When we counted it, it could not carry any of them. 1,618 products had been moved across during the migration. The list was good enough to raise an invoice, and useless for anything else.
| What we found | What it made impossible |
|---|---|
| Three fields all trying to say what a product is — a category field filled on just over half the items, a custom "type" field on half, and a product code that mixed what it is for with what it is | No single answer to "what kind of product is this". An item could be one thing in one field, blank in the second and something else again in its code. |
| "Category" actually held a specification, typed in freely — 57 different values for a handful of real ones, with the same spec written several ways, and 730 items with nothing | Nothing added up by product line. Every report needed cleaning in a spreadsheet before anyone would believe it. |
| Thirteen spellings of about five units of measure | To a report these look like different units, so quantities could not be added together at all. |
| 1,234 items with no selling price · 1,618 with no reorder level · 739 with no brand · 49 with no tax code | No automatic pricing on quotes, no margin by line, no low-stock warning, no brand analysis, no tax-ready stock summary. |
| Layer | The question it answers | What goes in it |
|---|---|---|
| 1 · Role | what is it for | Finished goods · part-made · raw material · packing material · consumable |
| 2 · Category | which family | Eight real product lines, agreed once |
| 3 · Sub-category | which variant | One level down inside each family |
| 4 · Specification | the measurable facts | Thickness, weight, grade, size, length, brand — each its own field, chosen from a list, never typed into a name |
| 5 · Commercials | what it costs and sells for | Selling price · cost price · reorder level · preferred vendor · tax code · one standard unit |
One product code scheme, built from role and category plus a number, so it sorts properly and explains itself — and it never has to carry the specification, because the specification now lives in a field. The product name is generated from those layers to one template, so nobody re-types a specification and no two people word it differently.
The clean-up was a one-time project of about 190 hours across six phases, over five to six weeks, so daily billing was never interrupted. 122 of those hours were the data work itself: standardising thirteen units into five, reclassifying all 1,618 items, lifting specifications out of names and into fields, re-coding the products, filling in 1,234 prices alongside the operations team, and setting reorder levels on the fastest-moving 400. Keeping it clean afterwards takes about five hours a month.
Three plants, running the same three stages, on work that arrives as a production order rather than as a phone call. The order is raised by a shortfall against a real customer order (2.5) — so every job on the floor can be traced back to somebody who is waiting for it, and key accounts reach the front of the queue without anyone being asked.
Two rules carry the whole of it. Material is issued against the production order and nothing else, so consumption and yield are known per job — which is the only way margin by product becomes a fact rather than an opinion. And a stage cannot start until the previous stage's quality entry exists, which is what turns a sequence of machines into a process you can actually measure.
| Stage | What the floor does | What the system takes from it | The gate before the next stage |
|---|---|---|---|
| Issue | Material drawn against this production order, and no other | Quantity issued, batch, which order consumed it | Nothing is drawn without an issue slip |
| Stage 1 | First operation on the raw material | Good output, waste, machine, operator, shift, minutes stopped | Set-up approved before the run — a check entry, not a nod |
| Stage 2 Convert | Cut, formed and joined to the specification on the order | Same, plus the specification actually run against the one ordered | In-process sample checked and logged |
| Stage 3 Pack | Counted, labelled and boxed to the customer's requirement | Pack counts and labels, matched to the order quantity | Checked before it leaves the line |
| Final gate | Whole job inspected against the order | Pass, rework or scrap, with a reason code and the operator | Only a pass releases it to the warehouse |
A rejection is never a conversation. It is a logged quantity, a reason code and a named operator, and it creates a rework order that re-enters the line at the stage it needs — then goes through the same gates again. If it cannot be saved it is scrapped against that order, so the cost lands on the job that caused it rather than disappearing into the month.
Because every rejection carries a reason code, the weekly question stops being are we having quality problems and becomes which stage, which machine, which shift, which reason, and how often. That list is what the service desk's complaint analysis (2.9) joins onto — a customer complaint and a line rejection about the same product finally meet in the same place.
| View | How often | The question it answers |
|---|---|---|
| Stage-by-stage status across all three plants | Live | Where is that order right now? |
| Planned output against actual | Daily | Are we on plan today? |
| Rejection rate by plant | Daily | Which plant, which stage, which reason? |
| Capacity use by plant | Daily | Do we have room for the key account's order? |
| Raw material position | Weekly | What runs out before the next purchase review? |
The company buys raw material for its own plants, buys finished goods from the factory it part-owns, and has trading items shipped straight from a vendor to the customer. All three run through one purchase flow and one vendor portal. The purchase order is downloaded there, accepted there, and the delivery proof and the bill are uploaded there. Payment status is visible there too — so the accounts team no longer answers "has my payment been released?" on the phone.
| Type | What starts it | Where the goods go | How the margin works |
|---|---|---|---|
| Raw material | A shortfall against production orders | To the plant or warehouse; goods receipt and incoming inspection | Consumed against a production order |
| Partner factory | A production order placed on the partner as a vendor | To the warehouse, or straight to the customer | What the partner charges against what the customer pays, tracked as its own cost centre with its own monthly profit statement |
| Trading / drop-ship | An order for a trading item creates a purchase order to the mapped vendor automatically | Vendor ships to the customer and uploads the proof | The company invoices the customer at the selling price and pays the vendor after the customer pays |
Before this, support lived in message threads: no ticket number, no category, no clock, and no way to tell whether a customer had complained before. Now every complaint — from the website form, the customer portal, a message, a phone call, or a chat the system recognises as a complaint — becomes a ticket that already knows which account and which order it belongs to. Proof of delivery is the hinge: it closes the order, opens the service window, and starts the three-day timer for the review request.
| Field | Required | What it drives |
|---|---|---|
| Name, company, phone | Yes | Matched to the customer account |
| Order number | No | Matched to the order; the delivery proof is attached to the ticket |
| Type of complaint — quality, wrong product, late, short delivered, billing, missing proof, other | Yes | Sets the category and the priority automatically |
| Description, and a photo | Yes / optional | Evidence on file, which is what goes back to the factory |
The same chat window serves sales and service. Who the visitor is, which pages they read and how long they stayed all arrive before the first message. A business enquiry becomes a sales record; complaint words route it to Zoho Desk instead; an after-hours chat with a contact becomes a record the next morning.
The service problem was never that complaints were handled badly. It was that the customer had no way of answering their own question, and the company had no way of counting the questions it answered.
No customer login. A customer could not see past orders, bills, payments, or where a live order had reached — so every one of those became a call, a message or an email, with the order number typed in as loose text. Whoever answered had to find the order first. Nothing linked the question to the order afterwards, so no order and no product ever built up a service history, and which of our products causes the most trouble? had no answer anywhere in the business.
Each account has its own login: order history, live status, bills, payments, delivery proofs, and a complaint raised against a specific order in two clicks. Questions that still arrive by phone, message or email are logged as tickets and mapped to the order they are about — so the link survives whichever way the customer chose to get in touch. The weekly complaint list is now a real list of products, orders and causes, and it goes back to the plant and to despatch, which is where a fault can actually be removed.
The portal reduces the number of contacts. The mapping is what makes the contacts you still get worth something: a complaint stops being only a problem to close, and becomes one data point about a product, a plant and a delivery route.
Hiring, joining, attendance and payroll are usually four spreadsheets and a messaging group. Here they are one chain — and the hiring end of it is the piece we actually built, rather than configured.
Zoho Recruit holds the recruiting data: candidates, job openings, departments and interviews. On top of it sits a custom hiring app, built on Zoho Catalyst, that runs a five-round funnel and keeps four of those modules in step with Recruit. Recruit stays the system of record. The app is the automation layer — screening, profiling, testing, scorecards, the director's decision, every candidate email, and the dashboard that reports on all of it.
| Round | What it is | What passes |
|---|---|---|
| R1 | AI screening — timed answers, as text or to camera, scored automatically | 70% or above |
| R2 | A 24-item behavioural profile, checked against the fit matrix for that role | Matches the role matrix |
| R3 | Skill test — multiple choice plus written, set per department | 65% or above |
| R4 | Department head, working from a structured scorecard | 70 or above, out of 100 |
| R5 | Director: strong yes · yes · hold · no | The director's call, then an offer |
Not every role runs all five. Junior roles run R1, R3 and R4. Mid-level roles run R1 to R4. Senior roles run the lot. And the flow itself is editable — HR can rename a stage, reorder the rounds, remove one, or add a manual stage of their own.
A failure is not automatically a rejection. Auto-reject is switched on by default for sales roles only. Everywhere else a candidate who misses a threshold is flagged "needs review" and a person decides. Good candidates who are not right for this opening go to a future-prospects pool, and can be reactivated against a new job in one action.
Four kinds of user — HR, department head, director, and any custom role HR defines — against a role-by-module access matrix. HR always keeps full access. Deletion is a separate permission, set per role.
Induction on day one with a short test. Product training in the first three days, with a pass mark. System training by day five, checked with a live entry. Role process training by day seven, signed off by the department head. Two to four weeks shadowing a senior colleague, first ten calls supervised. Half target in month two, full target in month three. On day ninety the decision — confirm, extend, or part — is documented.
| When | What happens |
|---|---|
| Daily | Attendance captured at each site, with location checking, and synced at the end of the day |
| Month end | The month is locked. Pay is calculated, with statutory deductions. Payslips go out. |
| Fixed dates | Tax deductions, employee insurance and provident fund files prepared from the same payroll data |
| Monthly | Sales tax returns compiled from the invoices; debtor ageing emailed to the credit insurer |
| Quarterly / yearly | Quarterly and annual tax returns compiled for the accountant from one set of records |
Every role has its own measures, reviewed weekly for sales and monthly for the rest, with an incentive that matches the job: collection efficiency for accounts, on-time delivery for despatch, satisfaction scores and review counts for service, production efficiency for the plant heads.
Leaving is a process too. Resignation recorded in the system, a conversation with the manager within a day, a structured exit interview, a signed handover document covering live work and key contacts, access withdrawn on the last day, and final settlement inside 30–45 days. Attrition is reported monthly by department.
Connecting everything is worth nothing if nobody reads what comes out. The rhythm is one Monday meeting fed by a report that builds itself on Sunday night, four other weekly reviews each owned by a named person, two daily bank checks, and a monthly compliance cycle on fixed dates.
| What it shows | Where it comes from | Target | If it is low |
|---|---|---|---|
| Total value of live deals, weighted by stage | Zoho CRM | Three times the monthly revenue target | Add 20+ new enquiries the same week |
| Meetings and calls over 15 minutes, per person | Zoho CRM | 8 per person per week | Under 5 — the manager coaches that person |
| Average order value, split by new, repeat and export | Order system | Set per segment | Review who the team is targeting |
| Gross margin percentage, by product line and by own versus partner manufacture | Order system | Above 30% blended | Review product mix, discounts and material cost |
| Also: orders won, new enquiries, at-risk accounts, export pipeline, review count and rating | Sales + service | — | — |
| When | The review | Owned by |
|---|---|---|
| Mon 10:00 | The weekly business review — pipeline, activity, conversions, order value, margin, escalations, key deals | Both directors and all of sales |
| Tue 11:00 | Vendor payment run — approved bills paid in one batch | Accounts head |
| Tue 15:00 | Purchase review — new orders approved, vendor confirmations checked | Operations director + purchasing |
| Wed 09:00 | Enquiry audit — both trade-portal accounts, every enquiry, follow-up done or not | Sales manager |
| Thu 11:00 | Despatch and delivery-proof review — pending despatches, overdue proofs, courier problems, marketplace orders | Operations director + despatch head |
| Fri 17:00 | Weekly scorecard — individual performance emailed to everyone | Sales manager → directors |
| Daily 09:00 & 18:00 | Bank reconciliation | Accounts |
| Monthly | Debtor ageing to the insurer · statutory dues · attendance locked and pay run · partner profit statement | Accounts + HR |
Directors: everything, plus approvals above set values for orders and purchases. Sales manager: the whole team's pipeline, discount approvals in the middle band, stuck-deal escalations. Salesperson: their own records only, product list read-only. Service: the desk in full, customer records read-only. Despatch: despatch and stock. Accounts: finance in full, customer records read-only. Plant heads: the manufacturing module. Reporting: read everything, change nothing, flag anything odd.
This is the register we keep. If an arrow appears on a diagram and does not appear in this table, it means a person is carrying paper. Keeping the register current is how the diagrams stay honest.
| # | From | To | What moves | What sets it off |
|---|---|---|---|---|
| 1 | Trade portal, account 1 | Zoho CRM | Enquiry, tagged to that account | Enquiry on the portal |
| 2 | Trade portal, account 2 | Zoho CRM | Enquiry, tagged separately so the two can be compared | Enquiry on the portal |
| 3 | Paid social advertising | Zoho CRM | Enquiry with the product they asked about | Form submitted |
| 4 | Spreadsheet lists | Zoho CRM | New rows; skipped if the phone number already exists | A row is added |
| 5 | Zoho Forms — enquiry | Zoho CRM | Enquiry, plus an acknowledgement to the customer | Form submitted |
| 6 | Zoho Forms — complaint | Zoho Desk | Ticket with its category and priority already set | Form submitted |
| 7 | Zoho SalesIQ | Sales system / service desk | A qualified chat becomes an enquiry with its source and owner; complaint words make it a ticket instead | Contact shared, or a keyword |
| 8 | Zoho ERP | The quote screen | That customer's own prices, live stock, taxes | A quote is opened |
| 9 | Zoho CRM | Zoho ERP | The order, created from a won deal — built to order, because no ready-made link between these two systems exists | A deal is marked won |
| 10 | Zoho Commerce checkout | Zoho ERP | Order → invoice → emailed to the customer, unattended. This is the one that replaced 600 hand-made documents a day. | An order is placed and paid |
| 11 | Marketplaces | Zoho ERP | Orders in, stock deducted, the right label format, returns | A platform order |
| 12 | Zoho ERP | Website and marketplaces | Live stock, so nothing is oversold | Stock changes |
| 13 | Zoho ERP | The customer | Confirmed · despatched with tracking · invoice · delivered | Status changes |
| 14 | Zoho ERP | Zoho CRM | Last order date, order and payment status, average monthly value | An invoice or a receipt |
| 15 | Bank, gateway, marketplaces | Zoho ERP | Statement lines and settlements | 9 AM and 6 PM |
| 16 | Zoho ERP | Service ticket | The order, its delivery proof and its invoice attach to the ticket — however the customer got in touch | A ticket is raised against an order |
| 17 | Zoho Commerce portal | Order system + service desk | Order history, live status, invoices, payments, delivery proofs; a complaint against a specific order | The customer, helping themselves |
| 18 | Delivery proof | Zoho CRM | Review request, and a reminder if there is no response | Three days after delivery |
| 19 | A review | Service desk / sales system | A poor rating raises a call alert; a good one tags the account as an advocate | A review is posted |
| 20 | Vendor portal | Zoho ERP | Order acceptance, delivery proof, bill, tax documents | The vendor, helping themselves |
| 21 | Attendance app | Payroll | Attendance from every site | Daily sync, month-end lock |
| 22 | Hiring app | Zoho Recruit | A job opening, published with every field Recruit requires — so it never arrives flagged incomplete | One click on publish |
| 23 | Zoho Recruit | Hiring app | Candidate records, pulled one way — Recruit stays the source of truth for who a person is | Continuous |
| 24 | Hiring app ↔ Zoho Recruit | both directions | Departments, and interviews scheduled, edited or cancelled on either side | Any change, either side |
| 25 | Hiring app → HR record | Payroll | Offer → employee record → salary structure | An offer is accepted |
| 26 | Zoho ERP | Accountant, insurer, tax portals | Tax return data, statutory files, debtor ageing | Fixed calendar dates |
| 27 | Every system above | Zoho Analytics | The weekly report and each role's dashboard | Continuous; sent Sunday 9 PM |
| Phase | Months | What went live | The gate before moving on |
|---|---|---|---|
| 1 · Foundations | 1–2 | The pipelines and the sixteen required fields; the enquiry feeds; user roles; team training; the hiring system's first live role | The old accounting package's chart of accounts, trial balance and stock balance verified to zero difference and signed by the accountant. Nothing was allowed to transact before that signature. |
| 2 · Sales automation | 2–3 | The 48-hour and 7-day nudges, the sample message, the 30 and 60-day repeat-customer flags, the web forms, the Sunday-night report, the director dashboard | No enquiry older than 48 hours without contact |
| 3 · Service | 3–4 | Ticket categories, response times, escalation; live chat routing; delivery proof made compulsory; satisfaction surveys; the review request | Every query through Zoho Desk, none resolved only in private messages |
| 4 · Order and money | 4–5 | Won deal → order → stock check → despatch → invoice; marketplace imports; bank reconciliation twice a day; the weekly payment run; debtor ageing to the insurer; tax data compiled; the partner factory set up as a vendor with its own cost centre | Zero hand-made invoices; zero reconciliation difference |
| 5 · The plants | 5 | All four production stages across all three plants; quality entries; rework; machine logs; the multi-plant view; attendance feeding payroll | Rejection rate visible daily, per plant |
| 6 · Everything connected | 6 | Customer portal, vendor portal, the website taking and billing its own orders, marketplace integration, live stock across all three channels, drop-ship running end to end, every dashboard | Enquiry → quote → order → production → quality → despatch → invoice → payment → review, with no manual step in the core chain |
The order is the lesson. Sales discipline first, because it produces the customer list that everything else keys on. Service second, because it is cheap and visible and buys goodwill for the harder work. The ledger only after the accountant had signed, because a system that starts from an unagreed position produces confident, worthless numbers. The plants after the ledger, so that costs had somewhere true to land. Portals and online channels last, because they show the whole chain to customers and vendors — and you must never show them a half-built one.
Two kinds of result sit below. The first is measured: things we counted before and counted again afterwards. The second is structural: work that no longer exists, or can no longer go wrong in the way it used to. The second kind is worth more, and it is the part a spreadsheet will never show you.
The first ninety days were spent on the shape of the sales process alone — before a single line of the order, stock or billing work had been built. This is what changed in that window.
Read those three numbers carefully, because the honest reading is the useful one. They are measures of behaviour, not of revenue. They say that when the process stopped contradicting itself, a team that was already working flat out could finally put its effort somewhere it counted — and that the company could, for the first time, see it happening.
| What used to happen | Now |
|---|---|
| 600 billing documents typed by hand every day, then emailed, printed and sent out with the goods | None. The website raises the invoice itself and emails it as the order is placed. |
| A week's website orders typed into the main system in one batch | Gone. The records are live to the minute. |
| About 40 hours a month cleaning up reports in spreadsheets before anyone would trust them | Under 2 hours. The structure underneath is finally sound enough to report from directly. |
| A day and a half each week preparing and then arguing about Monday's numbers | Zero preparation. The report builds itself on Sunday night. |
| Accounts answering "has my payment gone out?" for vendors, and "where is my order?" for customers | Both self-service. Two portals, no phone calls. |
| A first-round screening call for every applicant, by whoever was free, with no record of what was asked | Replaced. Every applicant is scored against the same rubric before a person spends a minute on them, and the two rounds that remain are human on purpose. |
| Quotes built from a handwritten rate sheet, or by ringing the owner | Priced by the system, from that customer's own agreed prices. |
It was billing. Not selling, not making, not delivering. Billing.
Around 200 orders arrived through the website every day, and the website was connected to nothing. Each order was billed by hand in a spreadsheet and produced three documents — customer copy, office copy, transporter copy. All 600 were emailed, printed and physically sent out with the goods. The day's orders were then typed into the main system once every seven days. Stock, receivables and revenue in the system were, on any given day, up to a week out of date — and the people quoting and despatching knew it, so they worked from the spreadsheets instead, which made the spreadsheets more true than the system.
The website is connected directly to Zoho ERP. The moment a customer places an order, the order is created, the tax invoice is raised against it, and it is emailed to the customer automatically. Stock moves, the accounts post and the debtor ageing updates in the same instant. The 600 documents a day stopped being made. The weekly typing batch stopped existing. And the company's own records became current to the minute rather than to the week — which is what makes every number in the weekly report worth reading in the first place.
The three-copy format itself did not disappear — the system prints it when a transporter needs it. What disappeared was a person producing it 600 times a day, and a seven-day gap between selling something and the company knowing it had.
Stock valuation by product line took about six hours of spreadsheet work. Dead stock, about eight. Fast movers, about eight. Stock ageing, six. Vendor performance, five. And three of the reports the business most needed — what to reorder, margin by product line, and consumption by specification — could not be produced at all, at any price, because the underlying data could not be grouped.
The same ten reports run from the cleaned structure in minutes rather than hours — roughly 40 hours a month of manual work reduced to under two. The three that were impossible are now routine: the low-stock reorder list, margin by product line, and consumption by specification. Nobody prepares them, and nobody can quietly adjust them on the way to a meeting.
| Area | Before | Now |
|---|---|---|
| Enquiry handling | Nine routes, answered differently by whoever was free; no source anyone trusted; an enquiry could exist nowhere | One record whatever the route, with a source, an owner, a pipeline and a one-hour clock — all set before the first call |
| Sales management | Judged on impression; two definitions of a won deal; 973 deals on a list nobody could see | One pipeline, one definition, every call recorded, a scorecard per person that nobody has to prepare |
| Quoting | A handwritten rate sheet, or a phone call to the owner; margin unknown at the moment of promising | Priced by the system from that customer's own agreed prices and live stock; margin visible before the number is given |
| Website orders | 600 documents typed daily; records a week behind | Order, invoice and email raised automatically; records live |
| Stock and products | 1,618 items that could not be grouped, priced or counted; no reorder levels | A five-layer structure, one product-code scheme, generated names, reorder levels on the fastest 400 |
| Manufacturing | The supervisor's notebook; costing once a year from totals | A production order per job, material issued against it, a quality entry at every stage, plan versus actual daily |
| Buying | Bills on a messaging app matched from memory; payment whenever there was a moment | System-drafted orders, one approval slot, a three-way match, one payment run a week, and a portal the vendor uses instead of the phone |
| Service | Message threads; no ticket, no category, no clock, no history | A ticket tied to the account and the order, a clock by complaint type, escalation on breach, a rating at closure, and a weekly list of causes that reaches the factory |
| Collections | Chasing from memory; ageing nobody trusted | A ladder with a named owner at every step, and ageing that reaches the insurer monthly without anyone preparing it |
| Pay and compliance | Four spreadsheets and a messaging group; statutory dues reconstructed later | Attendance at the site, the month locked, pay calculated from it, and filings on fixed dates from one set of records |
| Management reporting | A day and a half a week, and the numbers argued with anyway | One report built automatically on Sunday night, read on Monday morning |
We run the same review for manufacturers and distributors on Zoho ERP, Zoho CRM and Zoho One: count what is really happening in your systems, agree the process, then build it. Fixed-price proposal after a 30-minute call.
Book a free callWhatsApp +91 74395 16363Zoho ERP implementation