Hourglass Essentials Pvt Ltd — IT Division

Zoho Order Scenarios

Effective 1 April 2025 • Process Owner: R Roger Daniel Fernando • Version 1.0
01
Single Quote → Single Location (Standard SPO)
One client, one delivery point, one quotation, one SO. Standard fulfillment path. Most common scenario.
Standard
flowchart TD A([Lead / Inquiry Created]) --> B[Create Quotation
using Parent SKUs] B --> C{Feasibility Check
Shant / Manju} C -->|Approved| D[Pod Lead Approval] C -->|Not Feasible| B D --> E[Quote Sent to Client
7-Day Clock Starts] E --> F{Client Response} F -->|PO Received| G[Convert Quote → SO
Map Child SKUs] F -->|Email Only| H[RISK FLAG Raised
Pod Lead Accountable] F -->|No Response by Day 7| L{Pod Lead Decision} L -->|Extend Timeline| M[Quote Extended
RISK FLAG: Extension Granted
New Expiry Date Set] L -->|Do Not Extend| I([Quote Voided & Locked]) M --> N[ASM Follows Up
Document Extension Reason] N --> O{Client Response
by New Deadline} O -->|PO Received| G O -->|No Response| I H --> G G --> J[Add Delivery Instructions
and Kitting Notes] J --> K([Pass to Procurement]) style A fill:#0a2a30,stroke:#00e5ff,color:#00e5ff style K fill:#0a2a30,stroke:#00e5ff,color:#00e5ff style I fill:#2a0a10,stroke:#ff6b8a,color:#ff6b8a style H fill:#2a1a00,stroke:#ffb830,color:#ffb830 style M fill:#2a1a00,stroke:#ffb830,color:#ffb830 style L fill:#1a1200,stroke:#ffb830,color:#ffb830 style D fill:#0d1a0d,stroke:#7fff6e,color:#7fff6e
Step 1
Create inquiry, attach parent SKUs only (no decoration detail yet)
Step 2
Feasibility check with Shant/Manju before quote is sent
Step 3
Pod Lead approves; quote dispatched same day, 7-day timer starts
Step 4
PO received: convert quote to SO, ASM maps child SKUs
Step 5
Add delivery + kitting instructions in required format
Step 6
Clean SO passed to Balu (Procurement)
Extension
Pod Lead can extend quote validity beyond 7 days if valid reason exists (e.g., client requested extension, budget approval pending)
Risk Flag
ALL extensions are flagged as RISK in CRM; Pod Lead is accountable for extended quotes
Documentation
ASM must document: (a) Extension reason, (b) Client communication, (c) New expiry date, (d) Pod Lead approval timestamp
Max Extension
Maximum one extension of 7 days allowed; after 14 days total, quote must be voided or re-quoted with updated pricing
Price Review
If extended beyond 14 days, ASM must verify material costs haven't changed; update pricing if needed before re-quoting
Follow-up
ASM must follow up with client on Day 3, 5, and 7 of extension period; document all communication in CRM
02
Multiple Quotes → Multiple Locations → 1 Clubbed SO
Multi-cost-centre order. Separate quotations per cost centre, but procurement consolidates into a single SO for volume benefits.
Multi-Location
flowchart TD A([Single Inquiry]) --> B1[Quotation: Cost Centre A] A --> B2[Quotation: Cost Centre B] A --> B3[Quotation: Cost Centre C] B1 & B2 & B3 --> C[Pod Lead Approves All Quotes] C --> D{Client Releases PO} D -->|Per Cost Centre| E[Received: PO-A, PO-B, PO-C] D -->|Single PO| F[Received: 1 PO covering all] E & F --> G[ASM Creates NEW Single SO Manually
DO NOT convert quotes directly] G --> H[Add All Products Cumulatively
on Single SO] H --> I[Add All Delivery Locations
as Delivery Instructions] I --> J([Single SO → Procurement
Quantity Discounts Apply]) J --> K[Accounts Splits Invoice
per Cost Centre if Required] style A fill:#0a2a30,stroke:#7fff6e,color:#7fff6e style J fill:#0a2010,stroke:#7fff6e,color:#7fff6e style G fill:#1a2a10,stroke:#7fff6e,color:#7fff6e
Rule 1
Never convert individual quotations directly into separate SOs
Rule 2
ASM creates a new single SO manually, combining all locations
Rule 3
Delivery instructions carry location-level split, not separate SOs
Rule 4
Inquiry is master record; all quotations link back to it for reporting
Rule 5
Single SO enables quantity-based discounts from vendors
Rule 6
Accounts can issue split invoices per cost centre from one SO
03
Year-Long Program (Single Quote → Multiple SOs)
Annual programs (e.g. new joining kits). One quotation for total requirement, one annual PO, recurring SOs per delivery batch.
Program
flowchart TD A([Annual Program Inquiry]) --> B[Create 1 Quotation
for Total Annual Requirement] B --> C[Pod Lead Approves] C --> D[Client Releases Annual PO] D --> E{Monthly / Batch Trigger} E --> F[Create SO for Current Batch Only
e.g. 500 kits for March] F --> G[Procurement Purchases for
This Batch Only] G --> H[Delivery Executed] H --> E E -->|Program Complete| I([Inquiry Closed]) subgraph Reporting["Inquiry-Level Tracking"] R1[Total Quote Value] R2[Total SOs Raised] R3[Total Delivered] R4[Balance Remaining] end D --> Reporting style A fill:#2a1800,stroke:#ffb830,color:#ffb830 style I fill:#2a1800,stroke:#ffb830,color:#ffb830 style E fill:#1a1200,stroke:#ffb830,color:#ffb830 style Reporting fill:#1a1200,stroke:#4a5068,color:#c8cdd8
Rule 1
One quotation for full annual volume; do not re-quote each cycle
Rule 2
Create SO only for the batch being dispatched that cycle
Rule 3
Procurement buys only for current SO; no bulk pre-purchase
Rule 4
Inquiry tracks cumulative: quote value vs SOs raised vs delivered
04
Mixed Products — Size Known / Size Pending (Split SO)
Orders containing non-size products (proceed immediately) and apparel where size data is pending. Two SOs from one quotation.
Split SO
flowchart TD A([Inquiry with Mixed Products]) --> B[Create 1 Quotation
All Products via Parent SKU
NO 'Apparel TBD' entries] B --> C[Pod Lead Approves] C --> D[Receive PO for Full Order] D --> E[Create SO-1 Immediately
Non-Size Products
Mugs, Notebooks, Pop Sockets] D --> F{Await Client Size Data
DO NOT create a second quotation} E --> G[SO-1 Sent to Procurement] F -->|Size Data Received| H[Create SO-2
Apparel with Correct Child SKUs] H --> I[SO-2 Sent to Procurement] G & I --> J{Invoicing} J -->|Same Cost Centre| K[Accounts Clubs Both SOs
Single Invoice] J -->|Split Centres| L[Separate Invoices per Centre] subgraph NeverDo["NEVER DO"] ND1[Create 'Apparel TBD' as SKU] ND2[Create a second quotation
for the size-pending items] ND3[Delay SO-1 waiting for
size data] end style A fill:#2a0a18,stroke:#ff6b8a,color:#ff6b8a style F fill:#2a1020,stroke:#ff6b8a,color:#ff6b8a style NeverDo fill:#1a0a10,stroke:#4a5068,color:#ff6b8a style K fill:#0a2010,stroke:#7fff6e,color:#7fff6e style L fill:#0a2010,stroke:#7fff6e,color:#7fff6e
Rule 1
"Apparel TBD" is NOT a valid SKU. Never use it under any circumstance.
Rule 2
Dispatch SO-1 for non-size products immediately after PO receipt
Rule 3
Hold SO-2 until size data arrives; do not create a second quotation
Rule 4
Accounts clubs SO-1 and SO-2 into one invoice if required
Rule 5
If one cost centre is delayed, create SO for confirmed centres, hold for pending
Rule 6
Rush orders: never include size-pending apparel; use only catalogue items
05
Year-Long Program + Multi-Location Delivery
Annual program with recurring deliveries to multiple cost centres/locations. One annual quotation, batch-wise SOs with multi-location delivery instructions.
Program + Multi-Loc
flowchart TD A([Annual Program Inquiry]) --> B[Create 1 Quotation
For ALL Locations Combined
Annual Total] B --> C[Pod Lead Approves] C --> D[Client Releases Annual PO
May be 1 PO or Multiple per Centre] D --> E{Monthly / Batch Trigger} E --> F[Create SO for Current Batch
ALL Locations for This Cycle] F --> G[Add Delivery Instructions
Location A: 200 kits
Location B: 150 kits
Location C: 150 kits] G --> H[Single SO to Procurement
Volume Discounts Apply] H --> I[Delivery Executed
Multi-Location] I --> E E -->|Program Complete| J([Inquiry Closed]) subgraph Tracking["Critical Tracking"] T1[Quote: Total Annual Value] T2[SOs Raised: Per Batch] T3[Per Location Cumulative] T4[Balance Remaining] end D --> Tracking style A fill:#2a1800,stroke:#ffb830,color:#ffb830 style J fill:#2a1800,stroke:#ffb830,color:#ffb830 style F fill:#1a2a10,stroke:#7fff6e,color:#7fff6e style Tracking fill:#1a1200,stroke:#4a5068,color:#c8cdd8
Rule 1
ONE quotation for entire annual program across all locations
Rule 2
Each batch creates ONE SO covering all locations for that cycle
Rule 3
Delivery instructions must split quantities per location within single SO
Rule 4
Track cumulative delivery per location for program accountability
Rule 5
If one location delays, create SO for ready locations only, follow up separately
Rule 6
Accounts can split invoices per cost centre while procurement maintains volume discount
06
Year-Long Program + Size Data Pending
Annual program for apparel/size-based products where size collection happens per batch. Quote uses parent SKUs, SOs created after each batch's size data collection.
Program + Size TBD
flowchart TD A([Annual Apparel Program]) --> B[Create 1 Quotation
PARENT SKUs Only
Total Annual Quantity] B --> C[Pod Lead Approves
Feasibility for Parent Products] C --> D[Client Releases Annual PO] D --> E{Batch Cycle Trigger} E --> F[Collect Size Data
For Current Batch Only
e.g., March: 500 T-Shirts] F --> G{Size Data Received?} G -->|YES| H[Create SO with CHILD SKUs
T-Shirt Black S: 50
T-Shirt Black M: 120, etc.] G -->|NO - Delayed| I[HOLD: Track in CRM
ASM follows up weekly] H --> J[SO to Procurement] J --> K[Delivery Executed] K --> E I --> G E -->|Program Complete| L([Close Inquiry]) subgraph NeverDo["NEVER DO"] ND1[Create separate quotation
for each batch] ND2[Use 'Apparel TBD' SKU] ND3[Create SO without
confirmed size data] end style A fill:#2a0a18,stroke:#ff6b8a,color:#ff6b8a style I fill:#2a1a00,stroke:#ffb830,color:#ffb830 style NeverDo fill:#1a0a10,stroke:#4a5068,color:#ff6b8a
Rule 1
Quote uses PARENT SKUs with estimated annual quantity
Rule 2
NEVER create SO until batch-specific size data is confirmed
Rule 3
Each SO uses CHILD SKUs mapped from parent (ASM responsibility)
Rule 4
If size data delays, SO is held; ASM tracks and escalates to Pod Lead if >14 days
Rule 5
For urgent batch, offer catalogue items with known sizes as alternative
Rule 6
Track size data collection timeline per batch in inquiry notes
07
Multi-Location + Size Data Pending (Partial Locations)
Multiple locations, but some have size data ready while others are pending. Split into multiple SOs based on data readiness, not location count.
Multi-Loc + Split
flowchart TD A([Multi-Location Inquiry]) --> B[Create Separate Quotations
Per Cost Centre
Using PARENT SKUs] B --> C[Pod Lead Approves All] C --> D[Receive POs
Per Cost Centre or Combined] D --> E{Size Data Status Check} E -->|Locations A & B Ready| F[Create SO-1 Immediately
Locations A & B
With CHILD SKUs] E -->|Location C Pending| G[HOLD Location C
Track in CRM] F --> H[SO-1 to Procurement] G --> I[ASM Follows Up
Weekly for Size Data] I --> J{Size Data Received?} J -->|YES| K[Create SO-2
Location C
With CHILD SKUs] J -->|14 Days No Response| L[Escalate to Pod Lead
Client Contact Required] K --> M[SO-2 to Procurement] H & M --> N{Invoicing Decision} N -->|Same Client| O[Club SO-1 & SO-2
Single Invoice] N -->|Different Cost Centres| P[Separate Invoices] style A fill:#0a2a30,stroke:#7fff6e,color:#7fff6e style G fill:#2a1a00,stroke:#ffb830,color:#ffb830 style L fill:#2a0a10,stroke:#ff6b8a,color:#ff6b8a
Rule 1
Create separate quotations per cost centre using PARENT SKUs
Rule 2
Create SO-1 for ready locations immediately; DO NOT wait for pending locations
Rule 3
Track pending locations in CRM with weekly follow-up cadence
Rule 4
Escalate to Pod Lead if size data not received within 14 days
Rule 5
Each SO uses CHILD SKUs; ASM maps from parent at SO creation
Rule 6
For urgent locations, offer catalogue items or standard size packs
08
Complex: Year-Long Program + Multi-Location + Size Pending
Annual program with multiple locations, where size data is collected per batch per location. Highest complexity—requires meticulous tracking.
Maximum Complexity
flowchart TD A([Annual Program
Multiple Locations]) --> B[Create 1 Master Quotation
PARENT SKUs
All Locations Combined
Annual Total] B --> C[Pod Lead Approves] C --> D[Client Releases Annual PO] D --> E{Batch Cycle Trigger
e.g., March Batch} E --> F[Request Size Data
From ALL Locations
For Current Batch] F --> G{Size Data Readiness} G -->|Loc A & B Ready| H[Create SO-1
Locations A & B
CHILD SKUs
Current Batch Only] G -->|Loc C Pending| I[HOLD Location C
Track Separately] H --> J[SO-1 to Procurement] I --> K{Size Data Received?} K -->|YES| L[Create SO-2
Location C
CHILD SKUs
Same Batch Cycle] K -->|Delayed| M[Option 1: Wait
Option 2: Skip this batch
for Loc C, include in next] L --> N[SO-2 to Procurement] J & N --> O[Batch Deliveries Complete] O --> E M --> E E -->|Annual Program Complete| P([Close Inquiry]) subgraph Track["Multi-Dimension Tracking"] TR1[Per Location Cumulative] TR2[Per Batch Cumulative] TR3[Size Data Collection Status] TR4[Pending Follow-ups] TR5[Annual Balance Remaining] end D --> Track style A fill:#2a0a18,stroke:#ff6b8a,color:#ff6b8a style I fill:#2a1a00,stroke:#ffb830,color:#ffb830 style Track fill:#1a0a10,stroke:#4a5068,color:#c8cdd8
Rule 1
ONE master quotation for entire program (all locations, all batches)
Rule 2
Per batch: create SO for ready locations, hold pending ones
Rule 3
Track size data collection status per location per batch in CRM
Rule 4
If location delays, offer: (a) wait for next batch, (b) standard size pack, (c) catalogue alternative
Rule 5
ASM must maintain tracker: Location × Batch × Size Data Status × Delivery Date
Rule 6
Weekly review with Pod Lead for programs with >3 locations or >6 months duration
09
Order Amendments & Modifications Post-SO
Client requests changes after SO creation: quantity changes, product substitutions, cancellations. Requires strict change control process.
Change Control
flowchart TD A([SO Already Created]) --> B[Client Requests Change
Email/Call to ASM] B --> C{SO Status Check} C -->|Not Yet with Procurement| D[Amendment Possible
No Cost Impact] C -->|With Procurement| E[Check Procurement Status] C -->|Already in Production| F[STOP: Cannot Amend
Requires Cancellation] E --> G{Procurement Action} G -->|Not Yet Ordered| H[Amendment Possible
Update SO] G -->|PO Sent to Vendor| I[Contact Vendor
Check Amendment Feasibility] I --> J{Vendor Response} J -->|Can Accommodate| K[Amend SO and Vendor PO
May Have Cost Impact] J -->|Cannot Change| L[Inform Client
Options: Cancel & Reorder
or Accept Original] D --> M[ASM Updates SO
Add Amendment Note] H --> M K --> N[Document Cost Impact
Get Client Approval
if Price Changes] M --> O[Updated SO to Procurement] N --> O F --> P[Create New SO
for Changed Items] P --> Q[Original SO: Cancel
or Proceed as-is] L --> Q O --> R([Amendment Complete]) Q --> R style F fill:#2a0a10,stroke:#ff6b8a,color:#ff6b8a style I fill:#2a1a00,stroke:#ffb830,color:#ffb830 style M fill:#0d1a0d,stroke:#7fff6e,color:#7fff6e
Rule 1
ALL amendments must be in writing (email); no verbal changes accepted
Rule 2
Check SO status BEFORE confirming amendment feasibility to client
Rule 3
If procurement has sent PO to vendor, coordinate with Balu before client confirmation
Rule 4
Document ALL amendments in SO notes with: Date, Requester, Change Details, Approval
Rule 5
If price impact >5%, require fresh client approval via email before proceeding
Rule 6
Cancellations after production started: client pays for completed items + cancellation fee (if applicable)
10
Rush Orders with Constraints
Urgent delivery required (<7 days). Only catalogue items with known inventory accepted. No size collection, no customization beyond existing capabilities.
Rush / Express
flowchart TD A([Client Urgent Request
Delivery < 7 Days]) --> B{Feasibility Check} B -->|Catalogue Items Only| C[Check Inventory
with Procurement] B -->|Size Data Required| D[REJECT: Not Feasible
Offer Next Available Date] B -->|Custom Product| E[REJECT: Not Feasible
Offer Catalogue Alternative] C --> F{Inventory Status} F -->|In Stock| G[Create Quotation
Rush Order Flag
Add Express Charge] F -->|Not in Stock| H[Check Vendor TAT] H --> I{Vendor Can Deliver?} I -->|YES - Within 4 Days| G I -->|NO| D G --> J[Pod Lead Approval
Rush Flag Visible] J --> K[Quote Sent
24-Hour Response SLA] K --> L{Client Confirms?} L -->|PO Received| M[Convert to SO Immediately
RUSH FLAG in Caps] L -->|No Response in 24hrs| N([Auto-Void Quote]) M --> O[SO to Procurement
RUSH Priority] O --> P[Expedited Production
Daily Status Updates] P --> Q[Delivery Executed] D --> R[Offer Options:
1. Standard Timeline
2. Catalogue Alternative
3. Partial Rush Order] style A fill:#2a1800,stroke:#ffb830,color:#ffb830 style D fill:#2a0a10,stroke:#ff6b8a,color:#ff6b8a style E fill:#2a0a10,stroke:#ff6b8a,color:#ff6b8a style M fill:#0d1a0d,stroke:#7fff6e,color:#7fff6e
❌ NO
Size data collection — NOT ACCEPTED for rush orders
❌ NO
Custom products requiring production/sampling
❌ NO
Apparel with size breakdown — only standard packs
❌ NO
Multi-location delivery if locations not on same route
✓ YES
Catalogue items with CONFIRMED inventory only
✓ YES
Items vendor can deliver within 4 days
✓ YES
Standard decoration (if setup already exists)
✓ YES
Express charge 15-25% applied to client invoice
Rule 1
Rush = delivery <7 days. ONLY catalogue items with confirmed inventory
Rule 2
NO size collection for rush orders; offer standard size packs only
Rule 3
Express charge: 15-25% depending on TAT (documented in price list)
Rule 4
SO must have "RUSH" in caps in subject line when sent to procurement
Rule 5
ASM provides daily status update to client for rush orders
Rule 6
If unfeasible, offer: (a) partial rush for available items, (b) standard timeline for full order
Rule 7
Inventory MUST be checked with Balu BEFORE confirming rush to client
Rule 8
Quote validity: 24 hours only; auto-void if no PO received
11
Rush Order + Apparel (Standard Packs or Custom Ratios)
Client needs urgent delivery (<7 days) of apparel items. Standard size packs preferred. Custom ratios allowed ONLY if client provides exact breakdown immediately and inventory available.
Rush + Apparel
flowchart TD A([Client Rush Request
Apparel Items
< 7 Days]) --> B{Client Has Size Data?} B -->|No Size Data| C[Offer Standard Packs
or Single Size Only] B -->|Has Exact Size Breakdown| D{Data Provided Immediately?} D -->|YES - Immediate| E[Check Custom Ratio Feasibility] D -->|NO - Needs Time| F[REJECT Custom Ratio
Offer Standard Pack Instead] E --> G{Inventory Available
for Custom Ratio?} G -->|All Sizes Available| H[CUSTOM RATIO ACCEPTED
Higher Rush Charge 25-35%] G -->|Some Sizes Missing| I[PARTIAL: Offer closest
standard pack or adjust ratio] G -->|No Stock| F C --> J{Inventory Check} J -->|Option 1: Ready Stock| K[Standard Size Packs Available
e.g., S-M-L-XL-XXL: 5-15-20-15-5] J -->|Option 2: Vendor Stock| L[Vendor Has Pre-Packed
Standard Sizes in Stock] J -->|Option 3: Single Size| M[Offer Single Size Only
e.g., All Medium or All Large] J -->|No Stock| F K --> N[Create Quotation
STANDARD SIZE PACK
Rush Charge 20-25%] L --> O{Vendor TAT Check} O -->|Can Deliver in 4 Days| N O -->|Cannot Meet Deadline| F M --> N H --> P[Create Quotation
CUSTOM RATIO
Rush Charge 25-35%
RISK FLAG: Custom Ratio] I --> N N --> Q[Pod Lead Approval Required] P --> R[Pod Lead and Balu Approval
Verify Stock Reserved] Q --> S[Quote Sent
24-Hour Response Deadline] R --> S S --> T{Client Confirms?} T -->|PO Received| U[Convert to SO
RUSH FLAG with Size Details] T -->|No Response in 24hrs| V([Auto-Void Quote]) U --> W[SO to Procurement
RUSH Priority
Stock Reservation Confirmed] W --> X[Delivery Executed
No Exchanges Allowed] F --> Y[Offer Alternatives:
1. Standard pack rush
2. Standard timeline with custom
3. Single size rush] style A fill:#2a0a18,stroke:#ff6b8a,color:#ff6b8a style H fill:#2a1a00,stroke:#ffb830,color:#ffb830 style P fill:#2a1a00,stroke:#ffb830,color:#ffb830 style N fill:#1a2a10,stroke:#7fff6e,color:#7fff6e style U fill:#0d1a0d,stroke:#7fff6e,color:#7fff6e style F fill:#2a0a10,stroke:#ff6b8a,color:#ff6b8a
❌ NEVER
NO waiting for size data collection — client must provide immediately or accept standard pack
❌ NEVER
NO production of new apparel items — only existing inventory
❌ NEVER
NO procurement of missing sizes if custom ratio requested — must work with available stock
❌ NEVER
NO size exchanges post-delivery — client accepts final sizes as confirmed
✓ ALLOWED
Standard size packs (e.g., S-M-L-XL-XXL in 5-15-20-15-5 ratio) — PREFERRED option
✓ ALLOWED
Single size orders (e.g., 50 units all Medium, 100 units all Large)
⚠ CONDITIONAL
Custom ratios ONLY IF: (a) Client provides exact breakdown immediately, (b) ALL sizes in stock, (c) Higher rush charge 25-35%
⚠ CONDITIONAL
Custom ratios require Pod Lead + Balu approval; RISK FLAG raised; stock reserved immediately
Standard Pack
Use when: Client doesn't have exact sizes OR wants fastest delivery OR flexible on distribution. Rush charge: 20-25%. Lower risk.
Custom Ratio
Use when: Client has EXACT breakdown ready NOW AND all sizes available in stock. Rush charge: 25-35%. Higher risk; requires dual approval.
Example Standard
Client: "We need 100 T-shirts urgently, no specific sizes." → Standard Pack 1: S(10) M(30) L(35) XL(20) XXL(5)
Example Custom
Client: "We need 100 T-shirts urgently: 15 Small, 40 Medium, 30 Large, 10 XL, 5 XXL." → Custom ratio IF all sizes in stock
Critical Rule
If client requests custom ratio but ANY size is out of stock → MUST switch to standard pack or adjust ratio to available sizes
Time Limit
Client must provide custom ratio within 2 hours of rush request; beyond that, ONLY standard pack accepted
Pack 1
Basic 5-Size: S(10%) M(30%) L(35%) XL(20%) XXL(5%) — Total 100 units
Pack 2
Premium 6-Size: XS(5%) S(10%) M(25%) L(30%) XL(20%) XXL(10%) — Total 100 units
Pack 3
Corporate Bias: S(5%) M(35%) L(40%) XL(15%) XXL(5%) — Total 100 units
Pack 4
Single Size: All units in one size (M or L most common) — Client chooses size
Custom
Vendor's standard pack (if vendor has pre-defined ratio in inventory)
Rule 1
ASM MUST ask client: "Do you have exact size breakdown ready NOW? If yes, we can try custom ratio. If no, we offer standard size packs."
Rule 2
If custom ratio requested: Client MUST provide exact breakdown within 2 hours of initial request; ASM immediately checks stock with Balu
Rule 3
Custom ratio acceptance criteria: ALL sizes must be in stock; if ANY size missing, offer: (a) adjust ratio to available sizes, (b) switch to standard pack
Rule 4
Standard pack is PREFERRED and DEFAULT; push standard pack first before offering custom ratio option
Rule 5
Rush charges: Standard pack 20-25%; Custom ratio 25-35% (higher due to stock reservation complexity and exchange risk)
Rule 6
Quote must clearly state: "Standard Size Pack [Pack Name/Ratio]" OR "Custom Ratio: S(X), M(Y), L(Z), etc." — NO ambiguity
Rule 7
Client written confirmation required: "I accept [standard pack/custom ratio] as specified with NO SIZE EXCHANGES post-delivery"
Rule 8
Custom ratio orders require DUAL approval: Pod Lead + Balu; standard pack requires Pod Lead only
Rule 9
Stock reservation MANDATORY for custom ratios: Balu reserves exact sizes immediately after quote sent; no reservation for standard packs
Rule 10
SO documentation: "RUSH APPAREL — [Standard Pack X / Custom Ratio] — Sizes: [details] — No Exchanges"
Rule 11
RISK FLAG raised for all custom ratio rush orders; standard pack rush orders = lower risk, no flag needed
Rule 12
If client hesitates, offer priority order: (1) Single size (safest), (2) Standard pack (balanced), (3) Custom ratio (highest risk), (4) Standard timeline with full custom
Risk 1
Client complains about size distribution post-delivery → Prevention: Get written confirmation BEFORE quote approval (applies to both standard pack and custom ratio)
Risk 2
Client requests exchanges after delivery → Prevention: Quote & SO must state "No Exchanges for Rush Apparel" (applies to both standard and custom)
Risk 3
Custom ratio: One or more sizes out of stock after quote sent → Prevention: Reserve exact stock immediately after quote; double-check upon PO receipt
Risk 4
Custom ratio: Client provides size breakdown late (after 2 hours) → Prevention: Set clear 2-hour deadline; beyond that, switch to standard pack automatically
Risk 5
Custom ratio: Reserved stock gets sold to another order → Prevention: Balu marks reserved stock as "HOLD - Rush Order [Client Name]" in system immediately
Risk 6
ASM accepts custom ratio without checking all sizes in stock → Prevention: Mandatory dual approval (Pod Lead + Balu) ensures stock verification
Risk 7
Client unhappy with standard pack suggestion when custom ratio not feasible → Prevention: Explain upfront that custom ratio depends on 100% stock availability
Risk 8
Higher express charge for custom ratio not communicated clearly → Prevention: Quote must show: "Standard Pack: 20-25%" OR "Custom Ratio: 25-35%"
12
Online Store Stock Replenishment Orders
Internal orders to stock the online store inventory. No client PO required. Based on sales data and inventory levels. Bulk purchasing for catalog items with standard sizes/quantities.
Stock Order
flowchart TD A([Inventory Review Trigger]) --> B{Trigger Type} B -->|Monthly Review| C[E-commerce Manager Reviews
Sales Data and Current Stock] B -->|Low Stock Alert| D[System Alert: Item Below
Minimum Stock Level] B -->|New Product Launch| E[Decision to Add New
Product to Catalog] C --> F[Identify Replenishment Needs
Popular Items and Seasonal] D --> F E --> G[Define Initial Stock Quantity
Based on Market Research] F --> H[Create Stock Order List
Item, Quantity, Size Distribution] G --> H H --> I{Order Value Check} I -->|< ₹50k| J[E-commerce Manager Approval] I -->|₹50k - ₹2L| K[Pod Lead Approval Required] I -->|> ₹2L| L[MD Approval Required] J --> M[Create Internal SO
NO Client PO
Internal Reference Number] K --> M L --> M M --> N[Select Size Distribution
Based on Sales History] N --> O{Product Type} O -->|Apparel| P[Standard Pack: S-M-L-XL-XXL
Based on past sales ratio] O -->|Non-Apparel| Q[Order Standard Quantities
No Size Variants] P --> R[SO to Procurement
Mark as STOCK ORDER] Q --> R R --> S[Procurement Sources at
Best Wholesale Price] S --> T[Delivery to Warehouse/
Online Store Location] T --> U[Inventory Manager Updates
Stock Levels in System] U --> V[Products Listed/Updated
on Online Store] V --> W([Stock Available for Sale]) style A fill:#0a2a30,stroke:#7fff6e,color:#7fff6e style M fill:#1a2a10,stroke:#7fff6e,color:#7fff6e style R fill:#0d1a0d,stroke:#7fff6e,color:#7fff6e style W fill:#0a2a30,stroke:#7fff6e,color:#7fff6e
Internal
NO client PO required; internal stock replenishment order with internal reference number
No Quote
NO quotation created; direct SO creation based on inventory needs
Wholesale
Procurement sources at best wholesale/bulk pricing (not client pricing)
Generic
Catalog items only; NO customization, branding, or client-specific requirements
Standard Sizes
For apparel: standard size distribution based on historical sales data (not client sizes)
Warehouse
Delivered to company warehouse/online store location (not client premises)
Approval
Approval based on order value: <₹50k (E-com Manager), ₹50k-₹2L (Pod Lead), >₹2L (MD)
Timeline
No rush timeline; standard procurement (10-21 days acceptable)
Purpose
Stock Order: Replenish online store inventory | Client Order: Fulfill specific client requirement
PO Requirement
Stock Order: NO client PO; internal reference only | Client Order: Client PO mandatory (or risk flag)
Quotation
Stock Order: NO quotation; direct SO | Client Order: Quotation required before SO
Pricing
Stock Order: Wholesale/bulk pricing (cost-focused) | Client Order: Client pricing (margin-included)
Customization
Stock Order: NONE; generic catalog items only | Client Order: Often customized (branding, sizes, etc.)
Delivery
Stock Order: Company warehouse/store | Client Order: Client premises (single/multi-location)
Sizes (Apparel)
Stock Order: Based on sales history/market data | Client Order: Based on client employee data
Timeline
Stock Order: Flexible (10-21 days acceptable) | Client Order: Client-driven deadline
Rule 1
E-commerce Manager reviews inventory monthly OR system alerts when stock < minimum level
Rule 2
Stock orders based on: (a) sales velocity (fast-moving items), (b) seasonal trends, (c) new product launches
Rule 3
Minimum stock levels defined per product category; system alerts when 80% of stock sold
Rule 4
Apparel size distribution based on ACTUAL SALES DATA (last 6 months), NOT standard assumptions
Rule 5
SO created with internal reference: "STOCK-[YYYY-MM]-[Sequential Number]" (e.g., STOCK-2025-04-001)
Rule 6
SO notes must state: "STOCK ORDER - Online Store Replenishment - Warehouse Delivery"
Rule 7
Procurement targets LOWEST wholesale price; negotiate bulk discounts for large quantities
Rule 8
Quality check mandatory upon warehouse receipt; damaged items returned immediately to vendor
Rule 9
Inventory manager updates stock levels in system within 24 hours of delivery
Rule 10
Products auto-listed on online store if new; stock levels updated if existing product
Rule 11
NO urgent/rush stock orders; plan inventory to avoid stockouts (maintain 30-day buffer)
Rule 12
Track stock order ROI: Compare wholesale cost vs. online sale price; maintain minimum 40% margin
Tier 1
<₹50,000: E-commerce Manager approval only; routine replenishment orders
Tier 2
₹50,000 - ₹2,00,000: Pod Lead approval required; bulk orders or new product categories
Tier 3
>₹2,00,000: MD approval required; major inventory investment or new product line launch
Review
MD reviews quarterly report: Stock order spend vs. online sales revenue; margin analysis
T-Shirts
Based on 6-month sales: S(8%), M(28%), L(40%), XL(18%), XXL(6%) — Order total: 500 units
Notebooks
A5 (60%), A4 (40%) — No size variants; order based on sales velocity
Mugs
Standard capacity (300ml); order quantity based on monthly sales × 3 (90-day buffer)
Bags
Backpacks (55%), Tote bags (30%), Laptop bags (15%) — Based on category performance
Seasonal
Increase stock 2x for festive season (Oct-Dec); reduce to 0.5x during lean months (Jun-Aug)
New Products
Conservative initial order: 50-100 units for testing; scale up if sales velocity >10 units/week
Risk 1
Overstocking slow-moving items → Prevention: Order only fast-movers (>5 sales/month); test new products with small batches
Risk 2
Wrong size distribution → Prevention: Use ACTUAL sales data (last 6 months), NOT assumptions; adjust quarterly
Risk 3
Stock arrives damaged/defective → Prevention: Mandatory quality check upon delivery; immediate vendor escalation for returns
Risk 4
Stock sitting unsold >6 months → Prevention: Quarterly clearance sales for slow movers; donate if unsold after 12 months
Risk 5
Margins too low (<30%) → Prevention: Negotiate better wholesale pricing; discontinue products with <25% margin after 3 months
Risk 6
Stockout during peak demand → Prevention: Maintain 30-day buffer stock; double inventory before festive season
13
Client PO Amendment Post-Confirmation (Additional SO Creation)
Client adds new items or significantly modifies order AFTER SO created and sent to procurement. Create separate additional SO for new items. NEVER amend existing vendor PO; always create new vendor PO for additions.
Add-On Order
flowchart TD A([Original SO Created and Sent to Procurement]) B[Client Requests PO Amendment] C{Type of Amendment} D[Client Issues Additional or Revised PO] E{Check Significant Increase} F{Check New Product or Modification} G[Consider Amendment Check Vendor PO Status] H{Vendor PO Status} I[Amendment Possible Update Original SO] J[CANNOT Amend Vendor PO Must Create New SO] K[Create NEW SO Second Order for Additional Items] L[Link to Original Inquiry Reference Original SO] M[ASM Documents Add-On Information] N[Pod Lead Approval for New SO] O[NEW Vendor PO Created Separate from Original] P[Both SOs Track Separately Through Procurement] Q{Delivery Timing} R[Coordinate Delivery Both Orders Together] S[Separate Deliveries Track Independently] T[Update Original SO Document Amendment] U[Single Updated Vendor PO] V[Single Delivery] W{Invoicing Decision} X[Accounts Can Club Orders Single Invoice] Y[Separate Invoices Per PO] Z([Order Complete]) A --> B B --> C C -->|Add New Items| D C -->|Increase Quantity| E C -->|Change Specifications| F E -->|Over 20 Percent| D E -->|Under 20 Percent| G F -->|New Product Design| D F -->|Minor Modification| G G --> H H -->|Not Yet Sent| I H -->|Already Sent| J D --> K J --> K K --> L L --> M M --> N N --> O O --> P P --> Q Q -->|Same Delivery Window| R Q -->|Different Timelines| S I --> T T --> U U --> V R --> W S --> W V --> W W -->|Same Client Cost Centre| X W -->|Different POs Budgets| Y X --> Z Y --> Z style A fill:#2a1800,stroke:#ffb830,color:#ffb830 style K fill:#1a2010,stroke:#7fff6e,color:#7fff6e style J fill:#2a0a10,stroke:#ff6b8a,color:#ff6b8a style O fill:#0d1a0d,stroke:#7fff6e,color:#7fff6e style I fill:#2a1a00,stroke:#ffb830,color:#ffb830
❌ NEVER
NEVER amend a vendor PO after it has been sent — creates confusion, errors, and vendor disputes
❌ NEVER
NEVER merge new items into existing SO if vendor PO already sent — always create separate SO-2
❌ NEVER
NEVER accept verbal amendment requests — require written revised/additional PO from client
✓ ALWAYS
ALWAYS create NEW separate SO (SO-2) for additions/changes after vendor PO sent
✓ ALWAYS
ALWAYS create NEW separate vendor PO for SO-2 — keep original vendor PO unchanged
✓ ALWAYS
ALWAYS link both SOs to original inquiry for proper tracking and reporting
⚠ EXCEPTION
Amendment ONLY allowed if vendor PO not yet sent AND change is minor (<20% quantity increase or spec clarification)
Create New SO
Always create SO-2 if: (a) Vendor PO already sent, (b) New products added, (c) >20% quantity increase, (d) Different delivery timeline
Consider Amendment
Amendment possible only if: (a) Vendor PO NOT sent yet, (b) Minor change (<20% qty or spec clarification), (c) No cost impact, (d) Balu confirms feasible
When in Doubt
If unsure, DEFAULT to creating new SO — safer than amending; avoids vendor confusion and procurement errors
Rule 1
Client must provide written additional/revised PO; ASM documents reason for add-on (e.g., "Budget released for Phase 2")
Rule 2
ASM creates SO-2 with notes: "Add-On to SO-[Original Number]" + "Original PO: [PO-1]" + "Additional PO: [PO-2]"
Rule 3
Both SO-1 and SO-2 must link to same original inquiry for consolidated reporting and tracking
Rule 4
If SO-2 contains items similar to SO-1, ASM checks if bulk discount applies across combined quantity
Rule 5
Procurement creates separate vendor PO for SO-2; coordinates with vendor for combined or separate delivery
Rule 6
If client requests combined delivery, procurement informs vendor: "Please coordinate delivery of PO-[X] and PO-[Y] together"
Rule 7
ASM tracks both SOs in CRM; updates client with status of both separately or combined as per client preference
Rule 8
Accounts can club SO-1 + SO-2 into single invoice if same client PO budget/cost centre; or issue separate invoices
Rule 9
If SO-2 created due to size data arriving late (apparel), reference original quote; no new quote needed
Rule 10
If SO-2 contains entirely new products not in original quote, create fresh quotation for new items; get approval
Rule 11
Pod Lead approval required for SO-2 if: (a) value >₹50k, (b) new products, (c) different delivery location than SO-1
Rule 12
Maximum 2 additional SOs per inquiry allowed; if client requests 3rd add-on, treat as new inquiry/order
Scenario A
Size data delayed (Apparel): SO-1 for non-apparel items; SO-2 for apparel after size data received (Relates to Scenario 04)
Scenario B
Budget released in phases: SO-1 for Phase 1 items; SO-2 when Phase 2 budget approved; same products or new items
Scenario C
Additional location added: SO-1 for Locations A & B; client adds Location C later → SO-2 for Location C
Scenario D
Quantity increase (>20%): SO-1 for 500 units; client increases to 800 units → SO-2 for additional 300 units
Scenario E
Forgotten items: Client realizes they forgot to include notebooks in original order → SO-2 for notebooks
Scenario F
Rush add-on: Original order standard timeline; client needs urgent additional items → SO-2 marked RUSH with express charges
Same Quote
If SO-2 items were in original quote → Use original quoted prices; no re-quoting needed
New Quote
If SO-2 items are NEW (not in original quote) → Create fresh quotation; follow standard quote approval process
Bulk Discount
If SO-1 + SO-2 combined quantity qualifies for higher discount tier → Procurement negotiates; savings passed to client or retained (ASM decision)
Price Change
If material costs increased between SO-1 and SO-2 → ASM must inform client; get approval for revised pricing if >5% increase
Single Invoice
Accounts clubs SO-1 + SO-2 if: (a) same client, (b) same cost centre, (c) client requests combined billing
Separate Invoices
Issue separately if: (a) different PO numbers, (b) different cost centres, (c) staggered deliveries with separate payments
Risk 1
Vendor PO amended instead of creating new → Prevention: Balu NEVER amends sent POs; always creates new PO for SO-2
Risk 2
SO-1 and SO-2 not linked in CRM → Prevention: ASM must link both to original inquiry; use "Related SO" field
Risk 3
Client expects combined delivery but vendor sends separately → Prevention: ASM coordinates with Balu; Balu informs vendor explicitly
Risk 4
Pricing inconsistency between SO-1 and SO-2 → Prevention: ASM checks original quote; uses same pricing unless justified change
Risk 5
Multiple add-ons (>2) causing tracking chaos → Prevention: After 2nd add-on, treat further requests as new inquiry/order
Risk 6
Verbal amendment accepted without written PO → Prevention: ASM requires written additional PO; no verbal changes
14
Email Approval - PO Pending (Urgent Production Start)
Due to urgency, client provides email approval to begin production immediately. Formal PO will follow within agreed timeline. High-risk scenario requiring strict documentation and follow-up protocols.
Email Approval
flowchart TD A([Client Request Urgent Production Start]) B[Client Cannot Provide PO Immediately] C{Urgency Reason Valid} D[Client Sends Email Approval] E[ASM Reviews Email Approval] F{Email Contains Required Elements} G[ASM Requests Pod Lead Exception Approval] H{Pod Lead Decision} I[APPROVED Email-Based SO Creation] J[REJECTED Must Wait for PO] K[ASM Creates SO with RISK FLAG Email Approval Only] L[Set PO Deadline Date in CRM] M[ASM Documents Email in SO Notes] N[Vendor PO Created and Sent] O[Production Begins] P{PO Received by Deadline} Q[ASM Links PO to SO Removes RISK FLAG] R[SO Processing Complete] S[ASM Escalates to Pod Lead] T{Pod Lead Action} U[Contact Client Immediately] V[PO Received After Reminder] W[HALT Production No PO Received] X[Client Pays for WIP] Y[Order Complete] A --> B B --> C C -->|Valid Event Deadline Budget Approval Pending| D C -->|Not Valid| J D --> E E --> F F -->|Yes All Elements Present| G F -->|No Missing Info| J G --> H H -->|Approved| I H -->|Rejected| J I --> K K --> L L --> M M --> N N --> O O --> P P -->|Yes Within Deadline| Q P -->|No Deadline Passed| S Q --> R R --> Y S --> T T -->|Pursue PO| U U -->|PO Received| V U -->|No PO After 48 Hours| W V --> Q W --> X X --> Y J --> Y style K fill:#2a0a10,stroke:#ff6b8a,color:#ff6b8a style I fill:#1a2a10,stroke:#ffb830,color:#ffb830 style W fill:#2a0a10,stroke:#ff6b8a,color:#ff6b8a style Q fill:#0d1a0d,stroke:#7fff6e,color:#7fff6e
Required Element 1
Email must explicitly state: "Please proceed with production" or similar clear authorization language
Required Element 2
Email must reference quote number and total order value
Required Element 3
Email must commit to PO timeline: "PO will be issued by [specific date]"
Required Element 4
Email must be from authorized signatory (Procurement Manager, CFO, Director-level or above)
✓ Pod Lead Approval
MANDATORY Pod Lead approval required for ALL email-based SOs (no exceptions)
⚠ RISK FLAG
SO must be flagged "EMAIL APPROVAL ONLY - PO PENDING" until formal PO received
Rule 1
Maximum order value for email approval: ₹2L (orders above ₹2L require formal PO before production)
Rule 2
Maximum PO pending period: 7 working days (if no PO after 7 days, escalate to MD)
Rule 3
ASM must reply to email within 2 hours confirming: "Email approval received. PO expected by [date]. Production will commence."
Rule 4
ASM sets CRM reminder for PO deadline minus 2 days (e.g., if PO due Day 7, reminder Day 5)
Rule 5
ASM sends friendly PO reminder on Day 5: "This is a reminder that PO is expected by [date] as per your email approval"
Rule 6
If PO not received by deadline, ASM escalates to Pod Lead same day; Pod Lead contacts client within 24 hours
Rule 7
If no PO received 48 hours after Pod Lead escalation, HALT further production; client pays for work-in-progress
Rule 8
Once PO received, ASM immediately: (a) Links PO to SO in CRM, (b) Removes RISK FLAG, (c) Informs vendor PO received
Rule 9
Finance will NOT invoice until formal PO linked to SO (no exceptions)
Rule 10
Client history tracked: If client uses email approval >3 times in 6 months, require 50% advance payment for future orders
Valid Reason 1
Event-driven urgency: Corporate event, product launch, conference with fixed date - delivery must happen by specific date
Valid Reason 2
Budget approval pending: Client budget approved verbally but PO generation system delayed (finance processing time)
Valid Reason 3
PO system downtime: Client's procurement system temporarily down; manual PO will follow
Valid Reason 4
Multi-level approval in progress: PO requires CFO/MD signature; approval chain takes time but client needs production to start
INVALID Reason
Client convenience: "We'll send PO later when convenient" - NOT valid; must wait for PO
Risk 1
PO never received after production → Prevention: Daily tracking; halt production if no PO by deadline; client pays WIP costs
Risk 2
PO value differs from email approval → Prevention: Email must state exact value; if PO differs >5%, ASM clarifies before delivery
Risk 3
Client disputes order claiming no authorization → Prevention: Email must be from authorized signatory; ASM confirms designation before proceeding
Risk 4
Finance refuses to invoice without PO → Prevention: Set clear rule: NO invoice until PO linked; inform client upfront
15
PO Structure vs SO Creation Logic (Product-Delivery Focused)
Client PO can be structured in multiple ways (single, per cost centre, per product line, products vs services separate). However, SO creation is ALWAYS based on product grouping and deliverability (batch or whole), NOT client PO structure. SO is product-delivery focused.
SO Creation Logic
flowchart TD A([Client Sends PO - Any Structure]) B{PO Structure Type} C[Single Consolidated PO] D[Multiple POs per Cost Centre] E[Multiple POs per Product Line] F[Separate POs for Products vs Services] G[ASM Analyzes Total Order Regardless of PO Structure] H{SO Creation Decision Criteria} I[Group by Product Deliverability] J{Deliverability Check} K[All Items Ready for Immediate Delivery] L[Some Items Pending Size Data or Stock] M[Batch-Based Delivery Program] N[Create SINGLE SO All Items Together] O[Create SPLIT SOs SO-1 Immediate SO-2 Pending] P[Create BATCH SOs SO per Batch Cycle] Q[Link All SOs to Same Inquiry] R[Map PO Numbers to SOs] S[Finance Creates Invoices Based on PO Mapping] T[Vendor POs Created Based on SO Not Client PO] U([Delivery Executed per SO Logic]) A --> B B -->|Type 1| C B -->|Type 2| D B -->|Type 3| E B -->|Type 4| F C --> G D --> G E --> G F --> G G --> H H -->|Analyze Deliverability| I I --> J J -->|Immediate Delivery Scenario| K J -->|Split Delivery Scenario| L J -->|Program Scenario| M K --> N L --> O M --> P N --> Q O --> Q P --> Q Q --> R R --> S S --> T T --> U style G fill:#1a2010,stroke:#7fff6e,color:#7fff6e style I fill:#1a2010,stroke:#7fff6e,color:#7fff6e style N fill:#0d1a0d,stroke:#7fff6e,color:#7fff6e
✓ PRINCIPLE
SO creation is ALWAYS determined by product deliverability, NOT by how client structured their POs
✓ PRINCIPLE
One inquiry can have multiple client POs but SOs are created based on delivery logic (immediate, pending, batch)
✓ PRINCIPLE
Finance handles PO-to-invoice mapping; ASM focuses on product-to-delivery mapping via SOs
⚠ IMPORTANT
ASM must document ALL client PO numbers in inquiry notes; each SO references applicable PO(s)
Scenario A
Single Consolidated PO: Client sends 1 PO covering all items, all locations, all products → ASM creates SO(s) based on deliverability; single PO mapped to all SOs
Scenario B
Multiple POs per Cost Centre: Client sends PO-1 (CC-101 Mumbai), PO-2 (CC-102 Delhi) → ASM creates SO(s) based on delivery; finance maps invoices to respective POs
Scenario C
Multiple POs per Product Line: Client sends PO-1 (Notebooks), PO-2 (T-shirts), PO-3 (USBs) → If all deliverable together, ASM creates 1 SO; if T-shirts pending sizes, creates SO-1 (Notebooks+USBs) + SO-2 (T-shirts)
Scenario D
Products vs Services Separate: Client sends PO-1 (Physical products), PO-2 (Services like branding, kitting) → ASM creates SO for products only; services handled separately (not SO-based)
Scenario E
Hybrid: Client sends 3 POs (CC-based) but items include apparel (size pending) + catalogue items → ASM creates SO-1 (all catalogue items across all POs) + SO-2 (all apparel across all POs after sizes received)
Rule 1
ASM analyzes TOTAL order across all POs; identifies what can be delivered immediately vs pending vs batch-based
Rule 2
If all items across all POs are ready for immediate delivery → Create SINGLE SO (reference all PO numbers in SO notes)
Rule 3
If some items pending (size data, custom production) → Create SO-1 for ready items + SO-2 for pending items (both reference all applicable POs)
Rule 4
If batch delivery program → Create SO per batch cycle (SO-1 Batch 1, SO-2 Batch 2, etc.); each SO references original PO(s)
Rule 5
Multi-location orders: If all locations deliverable together → Single clubbed SO; if different timelines per location → Separate SOs per delivery schedule
Rule 6
ASM documents in SO notes: "PO References: PO-[X], PO-[Y], PO-[Z]" to link SOs to all applicable client POs
Rule 7
All SOs for same inquiry must link back to inquiry number for consolidated tracking and reporting
Rule 8
Vendor POs created based on SO product grouping, NOT based on client PO structure (vendor doesn't see client PO)
Rule 9
Finance receives SO(s) with PO mapping notes; creates invoices matching client PO structure for their accounting ease
Rule 10
If client PO structure conflicts with delivery logic, ASM explains to client: "Your POs will be honored for invoicing, but our SOs are created for efficient delivery"
Example 1
Client sends: 1 PO for 500 notebooks + 300 T-shirts (sizes pending) → ASM creates: SO-1 (500 notebooks) + SO-2 (300 T-shirts after sizes) → Finance invoices: 1 invoice referencing single PO (combines both SOs)
Example 2
Client sends: PO-1 (Mumbai CC-101), PO-2 (Delhi CC-102) all items ready → ASM creates: 1 clubbed SO (both locations) → Finance invoices: 2 separate invoices (Invoice-1 for PO-1, Invoice-2 for PO-2)
Example 3
Client sends: 3 POs (Notebooks, T-shirts, USBs) year-long program → ASM creates: SO-1 Batch 1, SO-2 Batch 2, etc. → Finance invoices: Per batch, split across 3 POs proportionally
Example 4
Client sends: PO-1 (Products ₹2L), PO-2 (Branding services ₹50k) → ASM creates: SO-1 for products only → Finance invoices: Invoice-1 for PO-1 (products), Invoice-2 for PO-2 (services, no SO)
Risk 1
Client expects invoice per PO but ASM created different SO structure → Prevention: ASM informs client upfront: "Your 3 POs will be honored for invoicing, but we'll deliver in 2 batches"
Risk 2
Finance confused by multiple POs mapped to single SO → Prevention: ASM clearly documents in SO: "References PO-[X], PO-[Y], PO-[Z]"; finance creates multiple invoices as needed
Risk 3
Vendor receives multiple vendor POs for same client → Prevention: This is normal; vendor POs follow SO logic; Balu coordinates delivery if needed
Risk 4
Client PO value total doesn't match SO total → Prevention: ASM reconciles before SO creation; clarifies discrepancies with client immediately
Scenario Comparison Matrix
Scenario Quotations Sales Orders PO Requirement Primary Risk Reporting Level
01 Standard SPO 1 1 PO or email (risk flagged) Email-only confirmation SO level
02 Multi-Location 1 per cost centre 1 clubbed (manual) PO per cost centre or 1 PO ASM converting quotes directly to separate SOs Inquiry level (quote per cost centre)
03 Year Program 1 (annual) 1 per batch cycle 1 annual PO Over-procurement; re-quoting each cycle Inquiry level (cumulative)
04 Split SO 1 (all products) 2 (SO-1 immediate, SO-2 on size data) 1 PO for full order "Apparel TBD" SKU usage; second quotation created Inquiry level; accounts clubs invoices
05 Program + Multi-Loc 1 (annual, all locations) 1 per batch (all locations combined) 1 annual PO or per cost centre Creating separate SOs per location; losing volume discount Inquiry level (per location + per batch tracking)
06 Program + Size TBD 1 (annual, parent SKUs) 1 per batch (after size data) 1 annual PO Creating SO without size data; using "Apparel TBD" Inquiry level (track size data collection per batch)
07 Multi-Loc + Size TBD 1 per cost centre (parent SKUs) Multiple (based on size data readiness) Per cost centre or combined Waiting for all locations before creating any SO Inquiry level (location × size data status matrix)
08 Maximum Complexity 1 (annual, all locations, parent SKUs) Multiple per batch (based on location readiness) 1 annual PO or per cost centre Losing track of location × batch × size data combinations Multi-dimensional: Location × Batch × Size Status × Delivery
09 Amendments Original quotation 1 (amended) or split if needed Original PO (amendment noted) Amending after vendor PO sent; verbal amendments SO level with amendment audit trail
10 Rush Orders 1 (catalogue items only) 1 (immediate conversion) PO within 24 hours Accepting rush with size data or custom products SO level with daily tracking
11 Rush + Apparel 1 (standard packs preferred; custom ratios conditional) 1 (immediate, with size details + no exchange clause) PO within 24 hours + written acceptance of sizes + no exchange acknowledgment Custom ratio without stock check; allowing exchanges; accepting size data after 2-hour window; single approval for custom ratio SO level; RISK FLAG if custom ratio; stock reservation for custom; no flag for standard pack
12 Stock Orders 0 (NO quotation; internal order) 1 (direct SO creation with internal reference) NO client PO; internal reference only (STOCK-YYYY-MM-###) Overstocking slow movers; wrong size distribution; low margins (<30%); stockouts during peak Approval by value: <₹50k (E-com Mgr), ₹50k-₹2L (Pod Lead), >₹2L (MD); quarterly MD review
13 Add-On Orders Original quotation (or new quote for new items) 2+ (SO-1 original; SO-2+ for additions; max 2 add-ons) Additional/revised PO from client (written); separate vendor POs for each SO Amending vendor PO after sent; not linking SOs in CRM; verbal amendments; pricing inconsistency; combined delivery expectation mismatch Inquiry level; both SOs linked; Pod Lead approval for SO-2 if >₹50k or new products; accounts can club invoices
14 Email Approval 1 1 (with RISK FLAG until PO received) Email approval then formal PO within 7 days; max order value ₹2L PO never received; unauthorized signatory; value mismatch; client disputes approval later SO level with RISK FLAG "EMAIL APPROVAL ONLY - PO PENDING"; mandatory Pod Lead approval; daily tracking
15 PO Structure Varies by PO structure (1 or multiple per cost centre/product line) Based on deliverability NOT PO structure (immediate/pending/batch logic) Any structure accepted (single, per cost centre, per product line, products vs services separate) Client expectation mismatch (expects SOs to mirror PO structure); finance confusion on PO-invoice mapping; ASM creates SOs matching PO instead of delivery logic Inquiry level for all linked SOs; finance handles PO-invoice mapping; ASM focuses on product-delivery mapping
Comprehensive Mitigation Plan for All Failure Scenarios
Failure Scenario Impact Mitigation Actions
Size Data Not Received (>14 Days)

CASE EXAMPLE: TechCorp Bangalore ordered 500 branded polo T-shirts (Q-2403, ₹87,500) on 15-Jan-2025 but delayed size data for new joiners. Week 1: ASM daily follow-up (no response). Day 10: Pod Lead called HR Manager - "Size collection in progress, need 1 week." Day 17: Still no data. ASM offered standard pack (S-15%, M-35%, L-35%, XL-15%) but client insisted on custom sizes. Day 22: Formal notice sent. Day 25: Client finally submitted sizes. Order delivered 18 days late. Learning: Build 14-day buffer for apparel orders.
SO creation blocked; delivery timeline at risk; client dissatisfaction Week 1: ASM daily follow-up via email
Week 2: ASM escalates to Pod Lead; Pod Lead contacts client decision-maker
Day 15: Offer alternatives: (a) standard size pack, (b) catalogue items, (c) push to next batch
Day 21: Mark as "Client Delay" in CRM; issue formal notice
Client Delays PO After Quote Approval

CASE EXAMPLE: Sunrise Pharma Mumbai - Quote Q-2418 for 2,000 notebooks + 1,500 USB drives (₹1.85L) sent 10-Feb-2025. Day 3: Reminder sent. Day 5: Procurement Manager said "Budget approval stuck with CFO." Day 7: ASM requested Pod Lead extension (granted - RISK FLAG raised). Day 10: Client "Need 2 more days." Day 12: PO received, delivered successfully. Outcome: ₹1.85L revenue saved; RISK FLAG justified due to CFO approval process. Learning: Corporate approval chains need 10-14 day quote validity.
Quote expires on Day 7; revenue loss; ASM time wasted Day 3: ASM sends gentle reminder
Day 5: ASM calls client; understands blocker
Day 6: Final reminder with quote expiry warning
Day 7 Option A: Quote auto-voided; ASM documents reason in CRM
Day 7 Option B: ASM requests Pod Lead approval for extension (if client has valid reason: budget approval pending, decision delayed, etc.)
If extended: RISK FLAG raised; Pod Lead accountable; maximum 7-day extension allowed; ASM follows up Day 3, 5, 7 of extension
Day 14 (max): If still no PO, quote must be voided; re-quote with updated pricing if client returns later
Year-Long Program: Batch Delivery Delays

CASE EXAMPLE: InfoTech Solutions Pune - 12-month new joiner kit program (T-shirts, notebooks, pens - ₹9.5L annually, 150 kits/month). Batch 4 (April 2025) delayed by vendor (fabric shortage). Day-14: Balu alerted ASM. Day-7: ASM informed client HR. Offered: (a) Wait 10 days, (b) Partial delivery 100 kits now, (c) Emergency source 50 from alternate (+₹8,500). Client chose (b). Compensation: Waived ₹3,200 delivery + 5% discount (₹4,500) on delayed 50. Outcome: Switched to backup vendor for Batches 5-12. Client satisfied.
Scheduled batch delayed beyond commitment date; client operations disrupted (e.g., new joiner kits unavailable); program timeline at risk Prevention: ASM tracks batch schedule in CRM with 7-day advance reminders; Balu confirms vendor readiness 14 days before batch date
Early warning: If vendor signals delay, ASM informs client within 24 hours with revised timeline
Client communication: Offer options: (a) Accept revised date, (b) Partial delivery of available items, (c) Emergency sourcing from alternate vendor at premium cost
Compensation: If delay caused by vendor/company: waive delivery charges; offer 5-10% discount on affected batch
Accountability: ASM documents delay reason; Pod Lead reviews if recurring issue with vendor
Escalation: If delay impacts client business operations (hiring freeze, event cancelled), MD contacts client with resolution plan
Year-Long Program: Annual PO Budget Exhausted Mid-Year

CASE EXAMPLE: RetailChain Ltd Hyderabad - Annual PO ₹12L for monthly merchandising kits (Batches 1-12). After Batch 7: Consumed ₹8.2L (68%). ASM projected: 5 batches × ₹1.4L avg = ₹7L needed, but only ₹3.8L remaining. Shortfall: ₹3.2L! Day 15: ASM alerted CFO with projection. Finance team slow. Day 28: Revised PO received (₹15L total, +₹3L added). Batches 8-12 delivered successfully. Learning: Alert at 70% consumption, not 80%, for PO amendment bureaucracy time.
Client's annual PO amount consumed before all batches delivered; remaining batches blocked; client needs additional items but PO ceiling reached Prevention: ASM tracks cumulative SO value vs annual PO amount after each batch; alerts client when 80% consumed
Projection: After each batch, ASM calculates: Remaining Batches × Avg Batch Value vs Remaining PO Amount
Early warning: If projection shows shortfall, ASM alerts client 30 days before next batch: "Your PO balance: ₹X; Estimated need: ₹Y; Shortfall: ₹Z"
Client options: (a) Issue revised PO with increased amount, (b) Reduce quantity/items in remaining batches to fit budget, (c) Extend program timeline to next fiscal year
Finance coordination: Accounts confirms PO amendment received before next batch SO created
Program adjustment: If client reduces scope, ASM updates master quote and batch schedule; gets written approval
Documentation: All PO revisions linked to inquiry; finance tracks amended PO numbers
Year-Long Program: Mid-Cycle Cancellation

CASE EXAMPLE: StartupHub Bangalore - 12-month welcome kit program (₹8.5L, ₹70k/batch). After Batch 5 (₹3.5L delivered), client faced Series A funding issues, cancelled. Batch 6 in-progress: ₹70k (vendor produced T-shirts). Fee: 5 batches (<6) = ₹10k penalty. Settlement: ₹3.5L + ₹70k + ₹10k = ₹4.3L. Pod Lead offered 3-month pause. Client declined (hiring freeze). MD sent closure letter. Outcome: Client returned 18 months later (post Series B) with ₹15L program. Relationship maintained.
Client cancels program after 3-4 batches delivered; remaining batches (6-8 months) voided; sunk costs in master quote preparation; vendor commitments at risk Policy: Cancellation allowed with 30-day notice; no penalty if >3 batches delivered; penalty if <3 batches (covers quote preparation costs)
ASM action: Understand cancellation reason; check if pause (temporary) or permanent termination
Vendor coordination: Balu informs vendor to halt future batch production; check if any batch in progress (must be paid for)
Financial settlement: (a) Client pays for batches delivered + in-progress batch, (b) Outstanding invoices settled within 15 days, (c) Cancellation charges if <3 batches: ₹10k or 5% of remaining program value (whichever lower)
Client communication: Pod Lead contacts client; offers alternatives: (a) Pause for 3-6 months and resume, (b) Reduce batch frequency (quarterly instead of monthly), (c) Complete cancellation with settlement
Documentation: Cancellation agreement signed; inquiry marked "Program Cancelled - [Reason]"; lessons learned documented
Relationship: MD sends formal closure letter; keeps door open for future business
Program + Multi-Location: Wrong Batch Delivered to Locations

CASE EXAMPLE: NationalBank - 6-location program. Batch 1 (Notebooks for Mumbai, Delhi, Bangalore). Batch 2 (USB drives for Chennai, Pune, Kolkata). Vendor error: Mumbai received USB drives, Chennai received notebooks. Discovered when Mumbai branch called (Day 2 post-delivery). Immediate escalation. Balu arranged inter-location transfer: Courier moved Mumbai USBs to Chennai, Chennai notebooks to Mumbai. Re-delivery cost ₹8,500 (company absorbed). Client got 10% discount on Batch 3 (₹12,000 value). Vendor penalized. Learning: Vendor must send dispatch plan 48 hours before delivery for ASM verification.
Location A receives Batch 2 items; Location B receives Batch 1 items; massive confusion; client operations disrupted; logistics nightmare Prevention: ASM creates location-wise delivery matrix in CRM: "Batch 1 → Loc A, B, C; Batch 2 → Loc D, E" etc.
SO documentation: Each batch SO MUST state: "Batch [Number] for Locations: [List]" in delivery instructions
Procurement verification: Balu double-checks vendor PO: "Deliver to [Location X, Y, Z] as per attached address sheet"
Vendor confirmation: Vendor sends dispatch plan 48 hours before delivery; ASM verifies correct location mapping
If error occurs: Immediate escalation to Pod Lead + Balu within 2 hours of discovery
Logistics fix: Coordinate location-to-location transfer OR vendor picks up from wrong location and re-delivers
Cost absorption: Company pays re-delivery costs; waives delivery charges for affected locations
Client communication: Pod Lead apologizes; provides corrected delivery timeline; offers 10% discount on next batch
Accountability: If ASM error (wrong SO instructions): retraining; if vendor error: vendor pays re-delivery; if Balu error: process review
Program + Multi-Location: Cost Centre Budget Mismatch

CASE EXAMPLE: Pharma Corp - 4 locations (Mumbai CC-101: ₹5L, Delhi CC-102: ₹3L, Bangalore CC-103: ₹4L, Chennai CC-104: ₹2L). By Batch 6: Mumbai consumed ₹4.8L (96%), Delhi ₹1.8L (60%). Batch 7 needed: Mumbai ₹60k (exceeds budget by ₹40k), Delhi ₹45k. ASM requested reallocation: Invoice Mumbai's ₹40k excess under Delhi's CC-102 (which had ₹1.2L surplus). Client finance approved via email. Batch 7 delivered: 2 invoices (Mumbai ₹20k under CC-101, ₹85k under CC-102 for Mumbai+Delhi items). Outcome: Program continued smoothly without budget amendment delays.
Location A's cost centre exhausted budget; Location B's budget underutilized; client finance rejects invoices; payment delays; ASM cannot club properly Prevention: ASM tracks budget consumption per cost centre after each batch; maintains running balance sheet
Tracking sheet: Location A (Cost Centre 101): Budget ₹5L, Consumed ₹3.2L, Remaining ₹1.8L | Location B (CC 102): Budget ₹3L, Consumed ₹1L, Remaining ₹2L
Pre-batch check: Before creating next batch SO, ASM verifies: "Location A needs ₹80k worth; CC 101 has ₹1.8L remaining - OK"
Alert threshold: When any cost centre reaches 90% consumed, ASM alerts client contact for that location
Reallocation option: If Location A budget exhausted but Location B has surplus, ASM asks client: "Can we invoice Location A's items under Location B's cost centre?"
Client coordination: Client finance approves budget reallocation in writing; ASM adjusts invoice mapping accordingly
If budget exhausted: (a) Client issues additional budget for that cost centre, (b) Skip that location in current batch and defer to next batch, (c) Combine with another cost centre (client approval)
Finance impact: Accounts creates separate invoices per cost centre; tracks payment separately; no clubbing across different cost centres without written approval
Documentation: All budget reallocations documented in CRM; client email confirmation attached to SO
ASM Creates Separate SOs for Multi-Location (Error)

CASE EXAMPLE: TechStartup - 3 locations (Bangalore, Pune, Hyderabad) ordered 1,000 branded water bottles + 500 notebooks. ASM created 3 separate SOs (SO-1 Bangalore, SO-2 Pune, SO-3 Hyderabad). Procurement rejected: "Must club for volume discount!" ASM immediately cancelled all 3 SOs, created single clubbed SO-4 for all locations. Delay: 1 day. Volume discount saved: ₹8,500 (from ₹82,500 to ₹74,000). ASM completed Scenario 02 refresher training. Learning: Multi-location ALWAYS = Single clubbed SO.
Loss of volume discount; procurement inefficiency; finance reconciliation issues Detection: Procurement rejects separate SOs; flags to Pod Lead
Immediate: ASM cancels incorrect SOs
Corrective: ASM creates single clubbed SO manually
Training: ASM completes refresher on Scenario 02
Prevention: CRM alert if multiple SOs created from same inquiry date
"Apparel TBD" SKU Used

CASE EXAMPLE: EduTech Company - Ordered 800 T-shirts (sizes pending). ASM created SO with line item "T-Shirt Apparel TBD - 800 units @ ₹250 = ₹2L". Procurement returned SO within 2 hours: "Cannot process TBD SKU, need child SKUs." ASM deleted TBD line, held SO. Day 5: Client submitted sizes (S-100, M-280, L-320, XL-80, XXL-20). ASM mapped to child SKUs (TS-BLK-S, TS-BLK-M, etc.), resubmitted SO. Processed successfully. Learning: NEVER use "TBD" in SO; hold SO until actual child SKUs available.
Procurement cannot process; SO stuck; vendor cannot quote Detection: Procurement returns SO immediately
Immediate: ASM deletes "Apparel TBD" line item
Corrective: ASM holds SO until size data received; maps to child SKUs
Training: ASM completes Scenario 04, 06, 07, 08 refresher
System Fix: Block "Apparel TBD" from SO creation (if possible in Zoho)
Amendment Request After Vendor PO Sent

CASE EXAMPLE: Marketing Agency Mumbai - SO-1 for 500 notebooks + 300 pens (₹45,000). Vendor PO sent on 15-Mar. Day 3: Client requested add 200 USB drives (₹18,000). ASM contacted Balu immediately. Vendor confirmed: "PO already in production, cannot modify. Send separate PO for USBs." ASM explained to client: (a) Add USB to existing order (delivery +7 days, vendor charges ₹2,500 modification fee), (b) Accept original order as-is + place new order for USBs. Client chose option (b). Created SO-2 for USB drives. Both delivered successfully on original timeline.
Vendor may reject; cost impact; delivery delay; client frustration Step 1: ASM contacts Balu (Procurement) immediately
Step 2: Balu checks vendor flexibility; gets cost impact estimate
Step 3: ASM presents options to client: (a) amendment with cost/delay, (b) accept original, (c) cancel & reorder
Step 4: Get written client approval for chosen option
Step 5: Document in SO notes; update delivery timeline in CRM
Rush Order Accepted Without Inventory Check

CASE EXAMPLE: EventCo Bangalore - Rush order for 300 branded caps (delivery in 4 days) for corporate event (₹24,000). ASM confirmed rush quote without checking inventory. Client sent PO immediately. Balu checked stock: Only 180 caps available! ASM escalated to Pod Lead within 1 hour. Pod Lead called client: "We can deliver 180 caps in 4 days, remaining 120 in 7 days." Client angry (event needs all 300). Solution: Waived ALL rush charges (₹4,800 refund) + emergency sourced 120 caps from alternate vendor (premium cost ₹6,000, company absorbed). All 300 delivered in 5 days. Client satisfied. ASM received formal warning + Scenario 10 retraining.
Cannot deliver on time; major client escalation; reputation damage Prevention: NEVER confirm rush order before inventory check
If occurred: Immediate escalation to Pod Lead
Client communication: Transparent disclosure within 2 hours; offer: (a) partial delivery of available items, (b) full order on realistic date
Compensation: Waive express charges; offer discount on next order
Accountability: ASM writes incident report; retraining on Scenario 10
Rush Order: Delivery Failure After Commitment

CASE EXAMPLE: LawFirm Delhi - Rush order 150 branded diaries for client gifting (3-day delivery, ₹18,500). Inventory confirmed, SO created, vendor dispatched Day 1. Courier: BlueDart Express. Day 2 evening: Tracking showed "Delay - Vehicle breakdown in transit." ASM informed client within 2 hours: "Courier issue, revised delivery Day 4." Client furious (gifting event Day 3). Emergency action: Arranged backup courier (Delhivery) from vendor, air shipped overnight. Delivered morning Day 3 (on time!). Cost: Waived rush charges ₹3,700 + backup courier ₹4,200 (company absorbed) + 15% discount on next order. Client relieved. Learning: For orders >₹50k, always arrange backup courier option.
Rush order confirmed and SO created; inventory verified; but courier/logistics fails to deliver within committed timeline; major client escalation; reputation damage Prevention: Use only reliable express courier partners with track record; confirm courier pickup time before committing to client
Backup planning: For critical rush orders >₹50k, arrange backup courier option; share tracking details with client real-time
Monitoring: ASM tracks shipment every 4 hours; escalates if any delay signal detected
Early warning: If courier signals delay (weather, vehicle breakdown, hub congestion), ASM informs client immediately; do NOT wait for deadline to pass
Client communication: Transparent disclosure within 2 hours of delay detection; revised ETA with buffer; sincere apology
Compensation: (a) Waive ALL rush charges (20-25% refund), (b) Waive delivery charges, (c) Offer 15-20% discount on next order, (d) Free upgrade to premium delivery next time
Escalation path: Pod Lead contacts client within 4 hours; MD contacts if client threatens legal action or relationship termination
Accountability: (a) If courier issue: courier company penalized; switch to alternate for future, (b) If ASM chose unreliable courier: formal warning, (c) If Balu delayed dispatch: process review
Post-incident: ASM documents full timeline; Pod Lead reviews logistics partner; considers blacklisting unreliable courier
Rush Order: Client Cancels After Expedited Processing

CASE EXAMPLE: StartupXYZ Pune - Rush order 400 T-shirts for launch event (5-day delivery, ₹68,000 including ₹13,600 rush charges). SO created Day 1. Vendor expedited production. Day 3: Client called "Event postponed, cancel order." ASM checked with Balu: Vendor already completed printing 250 T-shirts (₹42,500 WIP), courier advance paid ₹2,800. Sunk costs: ₹13,600 (rush) + ₹42,500 (WIP) + ₹2,800 (courier) + ₹6,800 (admin 10%) = ₹65,700. Pod Lead contacted client, offered: Convert to standard timeline (refund ₹10,000 rush charges) OR cancel and pay ₹65,700 sunk costs. Client chose conversion to standard timeline, accepted 250 completed T-shirts immediately + remaining 150 in 10 days. Outcome: Saved relationship, recovered most costs. Client flagged in CRM for future rush orders (50% advance required).
Client confirms rush order; ASM arranges express procurement; vendor expedites production; then client cancels order (budget cut, requirement changed); sunk express costs; vendor penalties Prevention: For rush orders >₹50k, ASM gets written commitment: "I understand rush order cancellation after processing incurs charges"
Policy documentation: Rush order quote must state: "Cancellation Policy - If cancelled after SO creation, client pays: express charges + work-in-progress costs + vendor cancellation fee"
If cancellation requested: ASM immediately checks with Balu: (a) Has vendor started production? (b) Has express courier been arranged? (c) What are sunk costs?
Cost calculation: Sunk costs = Express charges paid + Vendor WIP costs + Courier advance payment + Administrative overhead (10% of order value)
Client communication: ASM presents cost breakdown within 4 hours; "Your cancellation cost: ₹X (express charges) + ₹Y (vendor WIP) + ₹Z (courier) = Total ₹XX"
Negotiation: Pod Lead contacts client; offers options: (a) Convert to standard timeline (no rush charges), (b) Defer delivery by 7-10 days (partial refund of express charges), (c) Proceed with cancellation and pay sunk costs
Finance action: If client proceeds with cancellation, issue debit note for sunk costs; client must clear within 7 days
Vendor settlement: Company pays vendor for WIP; absorbs cost if client refuses (escalate to MD for decision)
Client relationship: If high-value long-term client, MD may waive 50% of cancellation charges as goodwill; document as exception
Future orders: Flag client in CRM as "Rush Cancellation History"; require 50% advance payment for future rush orders
Rush Apparel: Client Requests Size Exchanges Post-Delivery

CASE EXAMPLE: HealthcareCo Chennai - Rush order 250 branded jackets (3-day delivery for conference, ₹95,000). Client accepted Standard Pack 2 (S-15%, M-35%, L-35%, XL-15%) via written email. Delivered Day 3. Day 4: HR Manager called "Too many L sizes, need more XL." ASM referred to written confirmation email. Client insisted "didn't understand implications." Pod Lead contacted, explained policy. Offered 10% discount (₹9,500) on NEXT order with custom sizes (standard 14-day timeline). Client accepted compromise. Outcome: Maintained relationship; ASM now uses template: "Standard pack S-37, M-88, L-88, XL-37 = NO CHANGES ALLOWED post-delivery" with explicit size quantities, not just percentages. Client satisfied with discount offer.
Client unhappy with standard size pack distribution; requests exchanges; threatens to cancel future orders Prevention: MANDATORY written confirmation before quote approval: "I accept standard size pack [ratio] with NO EXCHANGES"
Quote documentation: Must state "Rush Apparel — No Size Exchanges — Standard Pack [Pack Name]"
SO documentation: Must state "RUSH APPAREL — Standard Pack [ratio] — No Exchanges Policy"
If client requests exchange: Politely refer to written confirmation; explain rush constraints accepted upfront
Goodwill option: Offer 10% discount on NEXT order with custom sizes (standard timeline); Pod Lead approval required
Escalation: If client escalates, Pod Lead contacts client; reiterates policy; offers future discount to maintain relationship
Learning: ASM documents incident; Pod Lead reviews if ASM failed to get proper written confirmation
Rush Apparel: Standard Pack Not Available After Quote Sent

CASE EXAMPLE: EventMgmt Bangalore - Rush order 180 T-shirts Standard Pack 1 (quote sent 10-Mar, ₹27,000). Client sent PO 11-Mar. ASM checked inventory: L size sold out overnight (another rush order processed)! ASM failed to reserve stock. Immediate Pod Lead escalation. Pod Lead called client within 1 hour: "L size unavailable; options: (a) Standard Pack 3 (different ratio), (b) Extend 4 days for new stock, (c) Reduce to 150 units with available sizes." Client chose (b). Compensation: Waived ALL rush charges (₹5,400 refund). Delivered Day 7 instead of Day 3. Client accepted. ASM received formal warning. Learning: MANDATORY stock reservation within 1 hour of sending rush apparel quote. Balu now marks stock "HOLD - Quote [Number]".
Inventory sold out between quote and PO; cannot fulfill rush commitment; major client escalation Prevention: ASM must RESERVE stock immediately after quote sent (coordinate with Balu)
Double-check: Confirm stock availability again when PO received before SO creation
If stock unavailable: Immediate escalation to Pod Lead within 1 hour of discovery
Client communication: Pod Lead contacts client within 2 hours; transparent explanation
Options: (a) Offer different size pack if available, (b) Extend deadline by 3-4 days for new procurement, (c) Waive express charges
Compensation: If client accepts extended timeline, waive rush charges completely; if client cancels, issue formal apology letter
Accountability: If ASM failed to reserve stock, formal warning; if procurement sold reserved stock, escalate to MD
Rush Apparel: Client Did Not Understand "Standard Pack" Concept

CASE EXAMPLE: FinanceCorp Mumbai - Rush order 300 polos for urgent client meeting (4-day delivery, ₹72,000). ASM mentioned "standard pack" in quote. Client sent PO. Day 2: Client called "We're collecting sizes from team now." ASM: "This is rush order with STANDARD pack - we cannot accept custom sizes." Client shocked: "Nobody told me that!" ASM reviewed email trail: Quote said "Standard Pack 2" but NO explanation of what that means. ASM error. Pod Lead offered one-time exception: Extend to 10 days (standard timeline), collect custom sizes, waive ALL rush charges (₹14,400 refund). Client accepted. Delivered with custom sizes Day 10. Outcome: ASM now uses mandatory template: "RUSH APPAREL: Standard Pack means FIXED size ratio (S-15%, M-30%, L-35%, XL-20%). You CANNOT provide custom sizes. Confirm: YES/NO." Client must reply YES to proceed.
Client thought they could provide custom sizes later; expects personalized distribution; claims miscommunication Prevention: ASM must EXPLAIN verbally + in writing: "Standard pack means pre-defined size ratio; you cannot customize sizes"
Best practice: Send sample email: "Rush orders accept ONLY standard size packs (e.g., Pack 1: S-10%, M-30%, L-35%, XL-20%, XXL-5%). You will NOT be able to provide custom size breakdown. Please confirm your acceptance."
If client claims misunderstanding: Review email trail; check if ASM sent clear explanation
If ASM explanation was unclear: Pod Lead offers one-time exception: extend timeline to allow custom size collection (waive rush charges)
If ASM explanation was clear: Politely refer to written confirmation; proceed with standard pack as agreed
Training: If this occurs, ASM must complete Scenario 11 refresher training with Pod Lead
Rush Apparel Custom Ratio: Size Out of Stock After Quote

CASE EXAMPLE: TechGiant Hyderabad - Rush custom ratio 400 T-shirts (S-50, M-120, L-150, XL-60, XXL-20) for product launch (5-day delivery, ₹1.12L). Balu + Pod Lead approved quote 12-Mar. Client sent PO 13-Mar. Balu checked stock: XXL only 8 units (12 short)! Another SO released reserved stock by error. Immediate escalation to Pod Lead + MD. Pod Lead called client within 1 hour: "XXL shortage of 12 units; options: (a) Adjust XXL to 8, add 12 to XL, (b) Standard pack same total quantity, (c) Extend 3 days for new XXL stock." Client chose (c). Compensation: Reduced rush charge 5% (₹5,600 waiver). Delivered Day 8. MD implemented new system: Reserved stock marked "LOCKED - Rush Custom [Client]" with automatic alerts if anyone tries to release. Procurement team member who released stock received formal warning.
Custom ratio accepted but one or more sizes sold out between quote and PO; cannot fulfill exact ratio; client escalation Prevention: Balu MUST reserve exact stock immediately after custom ratio quote sent; mark as "HOLD - Rush [Client Name]"
Double-check: Re-verify all sizes available when PO received before SO creation
If size unavailable: Immediate escalation to Pod Lead within 1 hour of discovery
Client communication: Pod Lead contacts client within 2 hours; transparent explanation
Options offer: (a) Adjust ratio to available sizes (if client flexible), (b) Switch to standard pack with same total quantity, (c) Extend timeline 3-4 days for procurement, (d) Reduce total quantity to match available stock
Compensation: If option (b) or (d) accepted, reduce rush charge by 5-10%; if option (c), waive portion of rush charge
Accountability: If Balu failed to reserve, formal review; if another order released reserved stock, escalate to MD; if ASM failed to verify, retraining required
Rush Apparel Custom Ratio: Client Late with Size Breakdown

CASE EXAMPLE: ConsultingFirm Delhi - Rush custom ratio request for 220 shirts (4-day delivery, ₹68,500). Balu confirmed all sizes available. ASM told client 10am: "You have until 12pm to provide exact size breakdown." 11:00am reminder sent. 11:30am reminder. 11:50am final notice. 12:05pm: No response. ASM switched to Standard Pack 1, sent quote. 12:20pm: Client called "We're ready with sizes!" ASM: "Deadline passed; we've quoted Standard Pack 1 per policy. Accept this OR switch to standard 12-day timeline with custom sizes." Client angry. Pod Lead intervened: High-value client (₹8L annual). Granted 1-hour extension. Client submitted sizes 12:45pm. Custom ratio quote sent. Order delivered Day 4. Outcome: Exception logged in CRM. Future rush orders from this client now have 3-hour deadline (not 2) as pre-approved exception for high-value status.
Client says they have sizes but takes >2 hours to provide; ASM waiting; rush timeline at risk Prevention: ASM sets clear expectation upfront: "You have 2 hours to provide exact size breakdown; beyond that, we proceed with standard pack"
2-hour timer: ASM sends reminder at 1 hour, 1.5 hours; final notice at 1:50
At 2 hours: If no size data, ASM automatically switches to standard pack option; informs client
Client protest: ASM explains rush constraint; offers: (a) accept standard pack for rush, (b) switch to standard timeline (10-14 days) with full custom sizes
Exception: Pod Lead can grant 1-hour extension ONLY if: client has strong reason AND high-value order (>₹50k) AND inventory confirmed available
Documentation: If exception granted, document reason in CRM; RISK FLAG raised
Rush Apparel Custom Ratio: Dual Approval Not Obtained

CASE EXAMPLE: ManufacturingCo Pune - Rush custom ratio 350 jackets requested (S-40, M-100, L-130, XL-60, XXL-20). ASM created quote, got Pod Lead approval (value OK). Sent quote without checking with Balu. Client sent PO immediately. ASM created SO. Balu received SO: "XXL stock only 5 units! Who approved this??" Immediate escalation. Pod Lead discovered: ASM bypassed Balu stock verification. Client informed within 2 hours. Options: (a) Adjust XXL to 5, (b) Extend 5 days for new stock, (c) Cancel. Client chose (a) + demanded compensation. Compensation: Waived 100% rush charges (₹17,500). Order delivered with adjusted ratio. ASM received written warning + 2-week suspension from rush orders. New system implemented: Zoho workflow now BLOCKS custom ratio quote creation unless both approvals logged (Pod Lead + Balu). Learning: DUAL approval is non-negotiable safety check.
ASM created custom ratio quote with only Pod Lead approval; Balu not consulted; stock verification missed; order fails Prevention: System/process check: Custom ratio quotes MUST have two approval signatures: Pod Lead + Balu
Detection: Pod Lead reviews all rush apparel quotes daily; flags any custom ratio without Balu sign-off
If detected before quote sent: Hold quote; get Balu verification immediately; proceed only if stock confirmed
If detected after quote sent: Immediate stock check with Balu; if ANY size missing, contact client to switch to standard pack or void quote
Accountability: ASM receives formal warning; must complete Scenario 11 training again
System improvement: If Zoho allows, implement quote approval workflow requiring two approvers for custom ratio rush orders
Location Tracking Lost (Complex Program)

CASE EXAMPLE: InsuranceCo - 5 locations, 12-month program, branded apparel (₹18L annual). Batch 3 (June): Mumbai needed 200 shirts (sizes pending), Delhi 150 (sizes received), Bangalore 180 (sizes received), Chennai 120 (sizes pending), Kolkata 100 (sizes received). ASM created tracking sheet but didn't update after size data received. Batch 3 SO created for "430 shirts" without location mapping. Vendor asked: "Deliver where?" ASM panicked - couldn't remember which locations had submitted sizes! Immediate Pod Lead escalation. Pod Lead + ASM reviewed all emails, reconstructed: Delhi-150, Bangalore-180, Kolkata-100 = 430 total. Created SO with proper location list. Mumbai + Chennai deferred to Batch 4. Delivered successfully. ASM mandated to use CRM location-batch matrix template: "Batch 3 | Mumbai (pending) | Delhi (ready 150) | Bangalore (ready 180) | Chennai (pending) | Kolkata (ready 100)". Template now mandatory for ALL multi-location programs in Scenarios 5, 7, 8.
Duplicate deliveries or missed locations; financial loss; client complaints Prevention: Mandatory tracker for Scenario 08 (Location × Batch × Size × Delivery)
Weekly review: ASM + Pod Lead for programs >3 locations
If tracking lost: Immediately audit all SOs raised for that inquiry
Reconciliation: Match SOs to client invoices; identify gaps
Client coordination: Request confirmation of received deliveries per location
Corrective action: Rebuild tracker; Pod Lead oversight for remainder of program
Quotation Created Without Feasibility Check

CASE EXAMPLE: RealEstateCo Kolkata - Requested quote for 800 branded ceramic mugs with company logo (₹96,000). ASM created quote without checking feasibility with Shant. Client approved quote immediately, sent PO. ASM forwarded to Balu. Balu contacted vendors: "Ceramic mugs require 500-unit minimum per design color. Client wants 2-color logo = 1,000 unit minimum, not 800." Infeasible! Immediate escalation. Pod Lead contacted client: "Our apologies - quote was sent in error. Ceramic mugs require 1,000 unit minimum. Options: (a) Increase to 1,000 units (₹120k), (b) Switch to steel mugs 800 units (₹92k), (c) Cancel." Client chose (b). ASM voided ceramic quote, created steel mug quote with 14-day validity (extended from 7 as apology). Order completed. ASM received formal warning. New mandatory workflow: Zoho blocks quote creation for custom/new products until feasibility checkbox marked by Shant/Manju.
Quote sent with infeasible product/price; quote must be voided; unprofessional image Prevention: Mandatory feasibility check with Shant/Manju before ALL quotes
If occurred: ASM immediately contacts client; apologizes; explains error
Corrective: Void incorrect quote; create revised quote post-feasibility check
Timeline adjustment: Extend quote validity by 7 days to compensate for delay
Accountability: ASM documents in CRM; Pod Lead reviews ASM's process adherence
Email-Only Confirmation (No PO) Accepted

CASE EXAMPLE: SmallBiz Jaipur - Email: "Please proceed with 500 notebooks as per quote Q-2511 (₹28,500)." ASM created SO immediately without PO. Delivered. Finance sent invoice. Client payment delayed 45 days. Finance: "Where's their PO?" ASM: "Email confirmation only." Finance: "We can't link invoice without PO number in system!" Client finally paid after multiple escalations but relationship strained. Pod Lead reviewed: Email didn't say "PO will follow" - just "proceed." High risk. New policy: Email-only acceptable ONLY if email explicitly states: "Please proceed. Formal PO will be sent by [Date]." If email doesn't commit to PO timeline, ASM MUST request PO before SO creation. ASM now uses template response: "Thank you! For our accounts process, please send formal PO. We'll start production immediately upon receipt." Compliance rate: 100%.
Payment disputes; lack of formal contract; finance rejects invoice Action: ASM raises RISK FLAG in SO notes
Documentation: Attach email confirmation to SO; CC Pod Lead
Finance coordination: Accounts pre-approved for email-based invoicing for this client
Follow-up: ASM requests formal PO post-delivery; links to invoice
Accountability: Pod Lead accountable for this decision; documented in CRM
Parent SKU Used in SO Instead of Child SKU

CASE EXAMPLE: MediaHouse Bangalore - Order 600 T-shirts with sizes (S-80, M-200, L-220, XL-80, XXL-20). ASM created SO with parent SKU "T-SHIRT-BLK-PARENT - 600 units @ ₹280 = ₹1,68,000". Sent to Procurement. Balu: "Cannot process parent SKU. Need child SKUs: TS-BLK-S, TS-BLK-M, etc." SO returned within 30 minutes. ASM corrected: Deleted parent line, added 5 child SKU lines (TS-BLK-S: 80 units, TS-BLK-M: 200 units, etc.). Resubmitted. Processed successfully. Delay: 2 hours. No client impact (within production timeline). ASM completed Scenario 4 refresher training. Learning: Zoho now has validation rule: Alert if parent SKU detected in SO line items; ASM must confirm "intentional" or correct to child SKUs before submission.
Procurement cannot place vendor order; SO stuck; delivery delayed Detection: Procurement flags and returns SO immediately
Immediate: ASM replaces parent SKU with correct child SKUs (sizes/colors)
Verification: ASM confirms with client if size breakdown matches their requirement
Training: ASM reviews SKU mapping process; Pod Lead monitors next 3 SOs
System: Implement SO validation rule to block parent SKUs (if Zoho allows)
Client Cancels Mid-Production

CASE EXAMPLE: RetailChain Ahmedabad - Order 1,200 branded bags + 800 notebooks (₹2.45L). SO created, vendor started production. Day 5: Client called "Cancel order - marketing campaign discontinued." ASM contacted Balu: Vendor completed 900 bags (₹1,35,000 WIP), purchased material for 300 bags + all notebooks (₹45,000 materials). Total sunk: ₹1.8L + vendor cancellation fee ₹12,000 = ₹1.92L. Pod Lead contacted client CFO: "Cancellation cost ₹1.92L. Options: (a) Accept 900 completed bags + cancel rest (pay ₹1.47L), (b) Complete full order (pay full ₹2.45L), (c) Cancel all (pay ₹1.92L sunk costs)." Client chose (a). Settlement: Client paid ₹1.47L, accepted 900 bags. Vendor kept materials (absorbed ₹45k loss). Outcome: Maintained client relationship. Client flagged: Future orders require 30% advance payment.
Sunk costs (materials, labor); vendor penalties; financial loss Policy: Client pays for: (a) completed items, (b) materials purchased, (c) vendor cancellation fee (if any)
ASM action: Contact Balu for exact cost breakdown
Client communication: Present cost impact within 24 hours; get written approval
Finance: Issue debit note for cancellation charges
Inventory: If items generic, add to stock; if client-specific, client must accept delivery
Documentation: Cancellation agreement signed by client
Delivery Address Missing or Incorrect

CASE EXAMPLE: LogisticsCo Chennai - Order 500 diaries (₹42,000). Client PO said "Deliver to Corporate Office." ASM created SO without specific address (assumed CRM had address). Vendor dispatched to old address in CRM (client had relocated 6 months ago). Day 3: Courier "Delivery failed - office not found." Client called: "Where's our order?" ASM checked: Wrong address! Client gave correct address (20km away). Courier charged ₹3,200 for address change + redelivery. ASM error (didn't verify address). Company absorbed cost. Delivered Day 5 (2 days late). Client complained to MD. Compensation: 10% discount on this order (₹4,200). Total cost: ₹3,200 courier + ₹4,200 discount = ₹7,400 loss. ASM received formal warning. New workflow: ASM MUST send delivery address confirmation email to client before creating SO: "Please confirm delivery address: [Address from CRM]." Client replies YES or provides updated address. 100% compliance.
Delivery failed; return shipping cost; timeline impact; client frustration Prevention: ASM double-checks delivery instructions in SO before sending to procurement
For multi-location: ASM sends delivery breakup to client for written confirmation
If occurred: ASM contacts client immediately for correct address
Logistics: Coordinate with courier for address update (if in transit)
Cost: If ASM error: company absorbs re-delivery cost; if client error: client pays
Follow-up: Update CRM with correct address for future orders
Stock Order: Overstocking Slow-Moving Items

CASE EXAMPLE: E-commerce Manager ordered 500 premium leather wallets (₹175/unit wholesale, ₹1,200 online price = 31% margin barely acceptable). Expected sales 20/week. Actual sales: 3-4/week. After 12 weeks: Sold only 42 units, 458 unsold (₹80,150 locked capital). Quarterly review flagged. Analysis: Premium segment too slow. Action: Clearance sale (₹850 online, 29% discount) + bundle offers (wallet + keychain combo). Sold 200 units in 4 weeks. Remaining 258 units donated to charity (₹45,150 write-off, MD approved). Learning: New premium items limited to 100 units initial order; monitor 8 weeks before scaling up. High-value stock orders now require pre-order proof (minimum 20% pre-sold before procurement).
Excessive inventory of products with low sales velocity; capital locked; storage cost; risk of obsolescence Prevention: Order ONLY fast-movers (>5 sales/month average over last 6 months)
New products: Conservative initial order 50-100 units; monitor first 4 weeks
Scale-up criteria: If sales velocity >10 units/week, double inventory; if <2 units/week, stop reordering
Detection: Monthly review flags items with <2 sales/month for 3 consecutive months
Action: Clearance sale (30-40% discount) for slow movers; donate if unsold after 12 months
Write-off: E-commerce Manager documents loss; MD approves write-off for dead stock >₹25k
Stock Order: Wrong Size Distribution (Apparel)

CASE EXAMPLE: Stock order 600 T-shirts using vendor's recommended Standard Pack (S-10%, M-25%, L-30%, XL-25%, XXL-10%). After 8 weeks: S sold 12/60 (20%), M sold 140/150 (93% - STOCKOUT!), L sold 170/180 (94% - STOCKOUT!), XL sold 80/150 (53%), XXL sold 8/60 (13%). Analysis: Actual sales distribution: M-38%, L-40%, XL-18%, S-3%, XXL-1%. Mismatch! Excess XL/XXL (220 units unsold). M/L stockout lost ₹45k sales (estimated 180 units at ₹250 avg). Learning: E-commerce Manager now generates size distribution report every quarter from actual sales data. Next order: 600 units = M-230, L-240, XL-108, S-18, XXL-4 (matches actual demand). Result: 95% sell-through in 6 weeks, minimal excess inventory.
Too many XS/XXL sizes that don't sell; shortage of M/L sizes causing stockouts; unbalanced inventory Prevention: Use ACTUAL sales data from last 6 months (not assumptions or vendor recommendations)
Analysis: E-commerce Manager generates size distribution report quarterly; adjusts ratios
Example: If last 6 months shows M(35%), L(40%), update order ratio accordingly (not standard 30-35%)
Regional factor: Adjust for regional trends if applicable (e.g., larger sizes in certain markets)
If imbalance occurs: Run targeted promotion for excess sizes; bundle with popular items
Corrective: Adjust next stock order to compensate (reduce excess sizes, increase shortage sizes)
Stock Order: Damaged/Defective Stock Received

CASE EXAMPLE: Stock order 400 premium notebooks from new vendor (₹125/unit wholesale, ₹320 online = 61% margin). Delivery received 15-Mar. Inventory Manager sampled 40 units (10%): Found 8 units with binding defects (pages falling out), 3 with cover damage. Defect rate: 27.5% - UNACCEPTABLE! Immediate vendor escalation with photos. Full batch inspection: 112/400 defective (28%). Vendor options: (a) Replace 112 units, (b) Credit note ₹14,000 (112 × ₹125). Vendor chose (a), sent replacement Week 2. Company kept defective units for internal use (office supplies). Vendor quality score: 28% defect = BLACKLISTED. Never ordered from this vendor again. Learning: New vendors require 20% sample inspection (not 10%) + signed quality guarantee agreement before bulk orders. Pod Lead now pre-approves all new vendor relationships.
Quality issues discovered upon warehouse receipt; cannot sell; vendor return required; revenue loss Prevention: MANDATORY quality check within 24 hours of delivery; sample 10% of each SKU
Inspection: Inventory Manager checks: packaging damage, product defects, color variations, size accuracy
Acceptance criteria: <2% defect rate acceptable; >2% triggers full batch inspection
If defective: Immediate vendor escalation; photograph evidence; email within 48 hours
Vendor action: Replacement OR credit note (vendor's choice); vendor pays return shipping
Documentation: Defect report in CRM; track vendor quality score; discontinue vendors with >5% defect rate
Stock Order: Low Margin Products (<30%)

CASE EXAMPLE: E-commerce Manager ordered 300 branded USB drives (₹280/unit wholesale, ₹380 online = 26% margin - BELOW 30% minimum). Expected high sales volume to compensate. After 2 quarters: Sold 280 units, revenue ₹1,06,400, cost ₹84,000, gross profit ₹22,400 (21% actual margin after discounts). Quarterly review flagged: "Unprofitable product." Pod Lead: "Negotiate better wholesale price OR discontinue." E-commerce Manager negotiated with vendor: ₹240/unit (14% wholesale discount) for future orders. New margin: 37% acceptable. If vendor refused, product would be discontinued. Learning: Products with <30% margin require quarterly renegotiation + proven volume justification. Low-margin products now capped at 10% of total inventory value. Focus shifted to 40%+ margin products.
Wholesale cost too high relative to online sale price; margins below target 40%; unprofitable inventory Prevention: Before stock order, verify: (Wholesale Cost × 1.67) ≤ Competitive Market Price
Margin calculation: Target 40% minimum; acceptable 30-40%; unacceptable <30%
Pricing strategy: If margin <40%, negotiate better wholesale price OR increase online selling price
Detection: Quarterly margin review; flag products with <30% margin for 2 consecutive quarters
Action: (a) Negotiate 10-15% wholesale discount with vendor, (b) Increase online price if market allows, (c) Discontinue if margin stays <25% after 3 months
Exception: Loss leaders (attract traffic) allowed if overall category margin >35%
Stock Order: Stockout During Peak Demand

CASE EXAMPLE: October (Diwali season): Branded diaries top seller (₹250 online, 45% margin). Stock: 200 units. Sales velocity jumped to 25/day (normal 8/day). Day 4: Stock alert 100 units (50%). E-commerce Manager ordered 500 units replenishment. Vendor lead time: 12 days. Day 8: STOCKOUT (200 units sold in 8 days). Days 9-20: Lost sales estimated 300 units × ₹250 = ₹75k revenue, ₹33,750 gross profit LOST. Customers bought from competitors. Day 20: Replenishment arrived (500 units). Post-Diwali demand returned to normal. Learning: Festive season requires 2.5x-3x buffer stock (NOT 2x). New protocol: Aug-Sep inventory planning for Oct-Dec peak. High-demand items now maintain 45-day buffer during peak season (not 30 days). Emergency sourcing protocol: If stockout imminent, source from premium vendor even at 10% higher cost (MD pre-approved).
Popular item out of stock during festive season/high demand; lost sales; customer dissatisfaction Prevention: Maintain 30-day buffer stock for fast-movers (sales × 30 days)
Seasonal planning: 2x stock for festive season (Oct-Dec); 1.5x for back-to-school (Jun-Jul)
Triggers: System alerts when stock reaches 80% sold; E-commerce Manager initiates replenishment
Lead time buffer: Account for 10-21 day procurement; order when 40-50% stock remaining
If stockout occurs: Pre-order feature on website; "Back in stock in X days" notification
Emergency action: Source from alternate vendor (even at higher cost) if demand critical; MD approval for premium sourcing
Stock Order: Approval Threshold Violation

CASE EXAMPLE: E-commerce Manager placed stock order for 800 premium bags (₹95/unit wholesale, ₹76,000 total). Created SO, sent to Balu. Finance review: "₹76k order - where's Pod Lead approval?" E-commerce Manager: "I thought threshold was ₹1L, not ₹50k." Policy violation. Finance held SO. Pod Lead reviewed: Product margin 42%, sales data showed demand for only 400 units/quarter (not 800). Pod Lead REJECTED order. E-commerce Manager revised: 400 units (₹38k) approved. Original order would have caused overstocking (400 excess units, ₹38k locked capital). E-commerce Manager received formal warning + retraining on approval thresholds. System fix: Zoho now blocks SO creation if value > user's approval authority. Hard stop implemented - cannot bypass. Result: Zero threshold violations in 12 months post-implementation.
E-commerce Manager placed >₹50k order without Pod Lead approval; process bypassed; budget overrun risk Prevention: System workflow enforces approval routing: <₹50k (auto-approve), ₹50k-₹2L (Pod Lead), >₹2L (MD)
Detection: Finance flags during SO review; check approval signature vs. order value
If violation occurred: Immediate escalation to Pod Lead; retrospective approval OR order cancellation
Accountability: E-commerce Manager receives formal warning; retraining on approval thresholds
Corrective: If order already placed, Pod Lead reviews feasibility; can cancel if unreasonable
System fix: Implement hard stop in Zoho preventing SO creation above authority limit
Quote Extension Pattern Abuse

CASE EXAMPLE: TextileCo Surat - Requested 6 quotes in 10 months (Q-2201, Q-2298, Q-2356, Q-2412, Q-2489, Q-2523). Each quote: Extension requested on Day 6, granted 7 days. Total extensions: 6. POs received: ZERO. CRM flagged: "Pattern Abuse - 6 extensions, 0 conversions." Pod Lead reviewed: Client using quotes for internal budgeting (not genuine orders). Pod Lead called client: "We've provided 6 quotes with extensions. Going forward, we require 25% advance deposit to process new quotes, refundable upon PO within 14 days." Client: "We're comparing vendors." Pod Lead: "Understood. Deposit policy applies to all new clients until first successful order." Client never returned. ASM time saved: ~12 hours. Learning: Clients with >3 quote extensions without PO automatically require deposit for future quotes. Genuine clients accept this; time-wasters drop off.
Same client repeatedly requests extensions; low conversion rate; ASM time wasted on non-converting leads Detection: CRM flags clients with >2 quote extensions in 6 months without PO
Analysis: Pod Lead reviews client history; determines if client is serious or time-waster
Action: For repeat offenders: (a) no further extensions granted, (b) require advance payment/deposit, (c) mark client as "Low Priority"
Communication: Pod Lead contacts client; explains new policy requiring commitment (deposit or signed LOI)
Policy: High-value clients (>₹5L annual) may get exception; all others follow strict 7+7 day rule
Extended Quote Pricing Outdated

CASE EXAMPLE: ExportCo Mumbai - Quote Q-2445 for 1,000 branded bags (₹145/unit, ₹1,45,000 total) sent 05-Feb. Day 7: Client requested extension (budget approval pending). Pod Lead granted 7 days (valid until 19-Feb). Day 14 (18-Feb): Client sent PO. ASM checked with Balu: "Bag wholesale cost increased from ₹95 to ₹110 (15.8% increase) due to raw material shortage." Original margin: 34%. New cost margin: 24% (UNACCEPTABLE - below 30%). ASM escalated to Pod Lead. Pod Lead called client: "Material costs increased 15.8%. Revised quote ₹165/unit (₹1,65,000 total). Options: (a) Accept revised price, (b) We absorb 5% increase (₹160/unit, ₹1,60,000), (c) Cancel order." Client chose (b). Company absorbed ₹5k loss as goodwill. Final margin: 30.6%. Learning: Extensions >10 days now require mandatory pricing recheck. If cost increase >10%, client MUST accept repricing (no absorption).
Material costs increased during extension period; margin loss if original price honored Prevention: ASM checks with procurement for price changes before any extension >7 days
Detection: Compare original quote date vs current material costs
Action: If cost increased >5%, inform client that quote requires repricing
Client choice: (a) Accept revised higher price, (b) Proceed with original if increase <5% (company absorbs), (c) Cancel
Documentation: If company absorbs cost difference, document in SO notes; Pod Lead approval required
Finance alert: Flag to accounts for margin review if absorption >₹10,000
Add-On Order: Vendor PO Amended Instead of Creating New

CASE EXAMPLE: PackagingCo Bangalore - SO-1 for 600 notebooks (Vendor PO-V1201 sent 10-Mar). Day 3: Client added 300 pens (SO-2 created). Balu AMENDED PO-V1201: Changed from "600 notebooks" to "600 notebooks + 300 pens." Vendor received amended PO, got confused: "Which is correct? Original or amended?" Vendor produced ONLY 300 pens (thought original was cancelled). Day 12: Delivery arrived - 300 pens, NO notebooks! Client furious. Immediate escalation to MD. Balu contacted vendor: "BOTH items needed!" Vendor: "Amended PO replaced original - standard practice." Massive confusion. Resolution: Vendor rushed 600 notebooks (3-day emergency production). Delay: 3 days. Client compensation: Waived delivery charges (₹2,400) + 10% discount on pens (₹1,350). Balu retrained. New policy: NEVER amend vendor POs. ALWAYS create separate PO for add-ons. Zoho now locks vendor PO editing after 6 hours.
Procurement amended existing vendor PO for add-on items instead of creating new PO; vendor confusion; wrong items delivered; billing disputes Prevention: Balu NEVER amends sent vendor POs; always creates separate PO for SO-2
Policy: "Once vendor PO sent, it is LOCKED; any additions require new PO"
Detection: Pod Lead reviews vendor POs weekly; flags any amendments to existing POs
If occurred: Contact vendor immediately; cancel amended PO; issue two separate POs (original + new)
Vendor communication: "Apologies for confusion. Please disregard amended PO. Proceed with original PO-[X] as-is. New items in separate PO-[Y]."
Accountability: If Balu amended PO, formal review of process understanding; retraining on Scenario 13
System: If Zoho allows, lock vendor PO editing after 24 hours of creation
Add-On Order: SO-1 and SO-2 Not Linked in CRM

CASE EXAMPLE: PharmaCorp Chennai - SO-1 for ₹85,000 (notebooks), SO-2 for ₹42,000 (USB drives). ASM created SO-2 but forgot to link to original inquiry (IN-2445). Client called Day 10: "What's our total order value?" ASM checked SO-1: "₹85,000." Client: "What about the USBs we added?" ASM searched SO-2 separately: "Oh yes, ₹42,000 more." Client: "So ₹1.27L total?" ASM: "Correct." Client unhappy: "You should know this without searching!" Pod Lead reviewed: SO-1 linked to IN-2445, SO-2 created as separate inquiry IN-2498 (error!). Accounts generated 2 separate invoices (missed clubbing opportunity). Client finance confused: "Why 2 invoices for 1 order?" ASM retroactively linked SO-2 to IN-2445. Accounts reissued clubbed invoice. Learning: SO-2 MUST reference original inquiry number in "Related Inquiry" field. Pod Lead now spot-checks all add-on orders for proper linking.
Cannot track total order value; reporting inaccurate; client inquiries show incomplete picture; accounts may miss clubbing invoices Prevention: ASM MUST link SO-2 to original inquiry AND reference SO-1 in notes
Linking method: Use "Related SO" field in Zoho; both SOs show same inquiry number
Detection: Pod Lead weekly review flags SOs with add-on notes but no linkage
If occurred: ASM retroactively links SOs in CRM; updates inquiry with total value (SO-1 + SO-2)
Reporting fix: Finance runs reconciliation; updates revenue reports with combined values
Client impact: If client asked for status and got incomplete info, ASM sends updated status covering both SOs
Accountability: ASM documents learning; Pod Lead spot-checks next 5 add-on orders from same ASM
Add-On Order: Client Expects Combined Delivery but Gets Separate

CASE EXAMPLE: HospitalityGroup Goa - SO-1 for 500 notebooks (Vendor A, ₹45,000). Day 5: Client added 300 pens (SO-2, ₹18,000). ASM created SO-2 but didn't ask about delivery preference. Balu sent separate vendor POs. Day 10: SO-1 delivered. Day 14: SO-2 delivered. Client called: "Why 2 deliveries? We wanted everything together!" ASM: "Different vendors, separate deliveries." Client angry: "You never asked! Now we paid DOUBLE delivery charges (₹2,400 × 2 = ₹4,800 instead of ₹2,800 combined)." Client demanded ₹2,400 refund. Pod Lead approved refund as goodwill. Learning: ASM MUST ask delivery preference when creating SO-2: "Do you want this delivered separately (faster) or wait for combined delivery (cost-efficient)?" Client chooses. Documented in SO notes. New template: "Delivery Preference: [Combined/Separate] - Confirmed with [Client Name] on [Date]."
Client frustration; logistics inefficiency; extra delivery costs; poor customer experience Prevention: ASM asks client explicitly: "Do you want both orders delivered together or separately?"
Documentation: ASM notes delivery preference in SO-2; informs Balu via email
Procurement action: Balu coordinates with vendor: "PO-[X] and PO-[Y] are for same client; please coordinate delivery together on [date]"
Vendor confirmation: Balu gets written confirmation from vendor that combined delivery is feasible
If vendors differ: ASM informs client upfront: "SO-1 from Vendor A, SO-2 from Vendor B; separate deliveries likely"
If expectation mismatch: ASM contacts client immediately upon discovery; offers: (a) wait for both to combine delivery, (b) proceed with separate, (c) hold SO-1 if not yet dispatched
Compensation: If company error caused issue, waive delivery charges for one order
Add-On Order: Pricing Inconsistency Between SO-1 and SO-2

CASE EXAMPLE: TradingCo Indore - SO-1 for 400 T-shirts @ ₹280/unit (₹1,12,000). Week 2: Client added 200 T-shirts (SO-2). ASM checked current pricing: ₹295/unit (vendor increased wholesale cost). Created SO-2: 200 units @ ₹295 = ₹59,000. Invoice sent. Client finance: "SO-1 shows ₹280, SO-2 shows ₹295 for SAME product? Explain!" ASM hadn't informed client about price change. Client refused to pay ₹59k: "Either ₹280/unit or cancel SO-2." Pod Lead reviewed: Vendor cost increased ₹12/unit (4.3%). ASM should have informed client before SO-2. Pod Lead offered: Honor ₹280 price (company absorbs ₹3,000 loss). Client accepted. Invoice revised: 200 units @ ₹280 = ₹56,000. Learning: ANY price change between SOs requires upfront client communication + written approval. If <5% increase, inform; if >5%, MUST get approval before SO creation.
Client charged different prices for same items in SO-1 vs SO-2; client disputes; trust erosion; margin impact Prevention: ASM checks original quote before creating SO-2; uses EXACT same pricing for same items
Justified changes: ONLY if (a) material costs increased >5%, (b) bulk discount applies to combined quantity, (c) client explicitly negotiated different rate
Price increase: If material cost up >5%, ASM informs client BEFORE SO-2 creation; gets written approval
Bulk discount: If SO-1 + SO-2 combined hits higher tier, ASM offers discount retroactively OR applies only to SO-2
Detection: Finance flags during invoice review if same SKU has different prices in linked SOs
If inconsistency found: ASM reviews reason; if unjustified error, issues credit note to client for difference
Client communication: Transparent explanation; apology if error; clear documentation of justified changes
Add-On Order: Multiple Add-Ons (>2) Causing Chaos

CASE EXAMPLE: ConstructionCo Nagpur - SO-1 (₹45k notebooks), SO-2 (₹28k pens), SO-3 (₹35k bags), SO-4 (₹22k USB drives), SO-5 (₹18k diaries). Total: 5 SOs, ₹1.48L across 6 weeks. ASM struggling to track: Which delivered? Which pending? Client called: "What's our total order?" ASM spent 20 minutes searching CRM. Finance generated 5 separate invoices. Client finance: "Why 5 invoices? This is chaos!" Vendor POs: 5 separate POs causing confusion. Accounting reconciliation: 4 hours. Pod Lead intervened after SO-3: "Stop adding! Next request = NEW inquiry." After SO-5 completed, Pod Lead called client: "For better service, future orders will be fresh inquiries (not add-ons). This ensures clean tracking." Client agreed. Learning: Maximum 2 add-ons enforced. SO-3 onwards requires MD approval for high-value clients only (₹5L+ annual). Regular clients: After SO-2, new inquiry mandatory.
Too many SOs (SO-1, SO-2, SO-3, SO-4...); tracking nightmare; vendor confusion; accounting complexity; team overwhelmed Prevention: Policy: Maximum 2 add-on SOs per inquiry; after SO-2, treat further requests as NEW inquiry
Explanation to client: "For orders with >2 add-ons, we create a fresh order for better tracking and service"
New inquiry benefits: (a) Fresh quote with current pricing, (b) Clean tracking, (c) Reduced errors
If client insists on linking: Pod Lead can make exception for high-value clients (>₹5L annual); requires MD approval
Exception handling: If >2 add-ons approved, dedicated ASM tracking sheet mandatory; weekly Pod Lead review
Reporting: Finance tracks total value across all linked SOs; flags if >5 SOs per inquiry for review
Learning: Analyze why client has so many add-ons; suggest upfront better planning for future orders
Add-On Order: Verbal Amendment Accepted Without Written PO

CASE EXAMPLE: AutomotiveCo Coimbatore - SO-1 delivered (₹65,000). Week later: Client called ASM "Also send us 200 keychains, same branding." ASM: "Sure, I'll add that." Created SO-2 (₹14,000), sent to vendor without written PO. Delivered. Invoice sent. Client: "We never ordered keychains! Who authorized this?" ASM: "You called and requested it." Client: "Prove it - where's the email or PO?" ASM had no written proof. Client refused payment. Pod Lead reviewed call logs (no recording). No email trail. Client insisted: "Your ASM misunderstood; we were just inquiring about pricing." Dispute. MD decision: Company absorbs ₹14k loss (vendor already paid). Keychains added to stock inventory. ASM received written warning. New policy: ZERO verbal-only add-ons. ASM must send confirmation email: "Thank you for adding 200 keychains (₹14k). Please reply CONFIRM or send revised PO to proceed." Client confirms in writing = proceed. No written confirmation = no SO created.
Client claims they never requested add-on; dispute over scope and payment; lack of documentation; ASM accountability issue Prevention: ASM NEVER accepts verbal add-on requests; requires written additional/revised PO
Policy: "All amendments must be documented in writing via email or revised PO"
Client communication: "Thank you for the request. Please send a revised PO or email confirmation, and we'll process the add-on immediately"
If client verbal only: ASM sends confirmation email: "As discussed, you're adding [items]. Please reply CONFIRM or send revised PO to proceed"
If SO-2 created verbally: ASM immediately requests written confirmation; holds vendor PO until received
If dispute occurs: Review email trail; if no written proof, ASM may need to absorb cost or void SO-2
Accountability: ASM who accepted verbal-only amendment receives formal warning; retraining on documentation requirements
Client relationship: For trusted long-term clients, verbal OK with immediate follow-up email; client replies CONFIRM within 24 hours
Email Approval (Scenario 14): PO Never Received After 7-Day Deadline

CASE EXAMPLE: BPOServices Bangalore - Email from Procurement Manager 05-Mar: "Please proceed with 800 T-shirts as per Q-2567 (₹1.85L). PO will be sent by 12-Mar (7 days)." Pod Lead approved (all 4 requirements met). Production started. ASM sent daily reminders. Day 5: Pod Lead called "PO being processed." Day 6: Pod Lead emailed CFO. Day 7: Final reminder. Day 9 (deadline+48h): NO PO. Balu halted production. WIP: 650 shirts completed (₹1.51L), 150 pending. Pod Lead sent formal notice. Client: "Approval process delayed, sending PO tomorrow." Day 10: PO received! Production resumed. Delivered Day 14. Outcome: Maintained relationship. Client flagged: Future email approvals require explicit "PO by [Date]" commitment + daily follow-up protocol active. Learning: 7-day deadline is FIRM. Day 9 production halt is non-negotiable.
Client gave email approval to start production urgently; formal PO was promised within 7 days; deadline passed; no PO received; production already started or completed; sunk costs; payment risk Prevention: Pod Lead MUST approve ALL email-only orders; validate 4 requirements (quote reference, order value, PO timeline with specific date, authorized signatory)
Daily tracking: ASM sends daily PO reminder emails to client starting Day 1 (template: "Gentle reminder: Formal PO due by [Date] as per email approval")
Escalation timeline: Day 5 (Pod Lead calls client contact), Day 6 (Pod Lead emails CFO/Procurement Manager), Day 7 (Final reminder with 48-hour grace period)
Day 9 (Deadline + 48h): If NO PO received, ASM escalates to Balu to HALT production immediately; calculate work-in-progress (WIP) costs
Client communication: Pod Lead sends formal notice: "Production halted due to pending PO. Current WIP: ₹X. Please provide PO immediately or settlement for WIP costs"
Options to client: (a) Send PO within next 48 hours (production resumes), (b) Cancel order and pay WIP costs + admin charges, (c) Accept completed items and settle payment
Settlement: If client pays WIP + admin, relationship maintained; if client refuses payment, escalate to MD + legal for recovery
Future orders: Client flagged in CRM as "Email Approval Delay History"; NO future email-only approvals allowed; require advance PO only
Email Approval: Unauthorized Signatory Sent Approval Email approval received from junior employee (e.g., Assistant Manager, Executive); later senior management denies authorization; payment dispute; company at risk Prevention: Pod Lead validates email signatory MUST be: Procurement Manager, Finance Manager, CFO, Director-level or above
Verification: Cross-check sender email domain (official company email only; no Gmail/Yahoo); verify signatory title in email signature
If unsure: Pod Lead calls client company and confirms: "We received email approval from [Name, Title]. Please confirm they are authorized to approve ₹X order"
Documentation: Save email approval + phone call notes + CRM entry with verification details
If unauthorized signatory used: Immediately discovered during verification, ASM rejects email approval; requests proper authorization
If discovered later: After production started, Pod Lead contacts client senior management with evidence; requests formal PO or written confirmation from authorized person
Client dispute: Present email evidence + phone verification notes; if client denies, escalate to MD + legal; recover costs via settlement or legal action
Company protection: All email-only SOs have mandatory Pod Lead approval to prevent junior ASM accepting unauthorized approvals
Email Approval: Order Value Mismatch (Email vs Final PO) Email approval states ₹X; client later sends formal PO with lower value ₹Y; client claims "changed requirements" or "budget cut"; revenue loss risk Prevention: Email approval MUST state exact quote number, order value, and item list to lock commitment
Detection: ASM immediately flags value mismatch when PO received; holds SO processing until resolved
Immediate escalation: ASM escalates to Pod Lead within 2 hours of PO receipt
Client communication: Pod Lead contacts client: "Your email approval on [Date] was for ₹X (Quote [Number]). PO received shows ₹Y. Please clarify the discrepancy"
Client options: (a) Issue revised PO matching original email approval value, (b) Provide written explanation for reduction + formal cancellation of reduced items, (c) Cancel entire order and pay WIP costs if production started
If production started: Calculate WIP costs; client must pay for work already completed OR issue full PO as per email approval
If client refuses: MD reviews case; decides: (a) Absorb loss to maintain relationship (if small value <₹20k), (b) Charge WIP costs (if substantial), (c) Legal action (if >₹1L and client acting in bad faith)
Documentation: All value mismatches logged in CRM; pattern tracked; if client has >2 instances, NO future email approvals allowed
Email Approval: Client Disputes Approval Later (Claims Email Was Unauthorized/Mistake) After production or delivery, client claims: "That email was sent by mistake" or "We never intended to place order"; disputes payment; company faces loss Prevention: Pod Lead validates email has ALL 4 requirements: (1) "Please proceed with production", (2) Quote number + order value, (3) PO timeline commitment, (4) Authorized signatory
Verification: Pod Lead confirms authorization via phone call before approving SO creation; documents call in CRM
If dispute occurs: Immediately escalate to MD; gather all evidence: email approval, phone verification notes, Pod Lead approval documentation
Legal response: Company lawyer sends formal notice with evidence; demands payment for delivered items or WIP costs
Client negotiation: MD contacts client senior management (CEO/CFO); presents evidence; seeks amicable settlement
Settlement options: (a) Client accepts full order and pays (relationship maintained), (b) Client pays 50% as settlement (MD discretion), (c) Client pays WIP costs only (minimum recovery), (d) Legal action (if client refuses all options)
Relationship impact: Client permanently flagged in CRM; NO future email approvals; advance payment (50%) required for future orders; Pod Lead approval mandatory for ANY future order
Internal accountability: Review whether Pod Lead verification was thorough; strengthen email approval process if needed
PO Structure (Scenario 15): ASM Creates SOs Matching PO Structure Instead of Deliverability Logic (Error) Client sends 3 POs (per cost centre); ASM creates 3 SOs instead of analyzing deliverability; loses volume discount; delivery confusion; finance reconciliation issues Prevention: ASM training emphasizes: "SO creation is based on deliverability (immediate, pending, batch) NOT PO structure"
Rule enforcement: Procurement reviews all multi-PO orders; flags if SOs mirror PO structure instead of delivery logic
Detection: Procurement rejects SOs; escalates to Pod Lead with explanation: "ASM created SOs per PO instead of delivery logic"
Immediate correction: ASM cancels incorrect SOs within same day; analyzes TOTAL order across all POs; creates correct deliverability-based SOs
Example correction: Client sent 3 POs (CC-101, CC-102, CC-103); ALL items ready to deliver → Create SINGLE SO referencing all 3 PO numbers (volume discount preserved)
Client communication: ASM proactively informs client: "Your 3 POs received. We've created 1 consolidated SO for immediate delivery to maximize volume discount. Invoice will reference all 3 PO numbers"
Retraining: ASM completes Scenario 15 refresher training; reviews deliverability logic examples
Accountability: Pod Lead tracks ASM error rate; if >2 PO-matching errors in 6 months, formal performance review
PO Structure: Client Expects SOs to Mirror PO Structure (Expectation Mismatch) Client sends 3 POs and expects 3 separate SOs + 3 separate invoices; ASM creates 1 consolidated SO; client finance confused; disputes invoice; payment delayed Prevention: ASM proactively communicates BEFORE SO creation when multiple POs received
Communication template: "Thank you for your 3 POs (per cost centre). We analyze all orders based on deliverability logic. Since all items are ready, we'll create 1 consolidated SO to maximize volume discount. Your invoice will reference all 3 PO numbers for your finance team to map correctly. This approach saves you ₹X through volume discount!"
If client insists on separate SOs: ASM escalates to Pod Lead; Pod Lead contacts client: "Separate SOs will lose volume discount of ₹X. Are you sure you want to proceed?"
Client education: Pod Lead explains Scenario 15 logic: "Our SOs are delivery-focused, not PO-focused. Finance handles PO-invoice mapping seamlessly. You still get your 3 invoices mapped to your 3 POs"
If client still insists: Pod Lead can approve separate SOs as exception (client explicitly accepts volume discount loss in writing)
Invoice solution: Accounts creates invoice(s) as client prefers: (a) Single invoice referencing all 3 POs, (b) 3 separate invoices (mapped to 3 POs) from single SO, (c) 3 separate invoices from 3 separate SOs (if exception approved)
Documentation: All client exceptions logged; preference saved in CRM for future orders
PO Structure: Finance Department Confusion on PO-Invoice Mapping Client finance receives invoice referencing multiple PO numbers; doesn't understand how to process payment; asks for separate invoices per PO; accounts reconciliation issues Prevention: When multi-PO order processed, ASM coordinates with Accounts: "This order has 3 client POs. Please prepare invoice mapping clearly"
Invoice format: Invoice clearly states: "This invoice covers delivery as per PO-001 (₹X), PO-002 (₹Y), PO-003 (₹Z). Total invoice: ₹(X+Y+Z)"
Supporting document: Accounts attaches PO-invoice mapping sheet: "PO Number | PO Value | Items Covered | Invoice Reference"
If client finance confused: Accounts team contacts client finance directly; explains: "Your 3 POs covered items delivered together. We've mapped all 3 PO numbers to this invoice for your reference"
Client request for split invoices: Accounts can split single invoice into 3 invoices (mapped to 3 POs) if client finance requires it; charges nominal admin fee ₹500 per additional invoice
Escalation: If client CFO escalates invoice mapping concerns, Pod Lead contacts client with Scenario 15 documentation; explains deliverability-based SO logic + PO-invoice mapping flexibility
Finance coordination: MD approves waiving split invoice charges for high-value clients (>₹5L annual) to maintain relationship
Future prevention: For repeat clients with finance confusion history, ASM confirms invoice preference upfront: "Do you want single invoice or separate invoices per PO?"
PO Structure: Cost Centre PO vs Consolidated Delivery SO (Client Confusion) Client sends POs per cost centre (CC-101, CC-102, CC-103); ASM creates consolidated SO for immediate delivery; client expects separate deliveries per cost centre; receives single combined delivery; operations disruption Prevention: When client sends cost centre-based POs, ASM analyzes delivery requirement: "Does client want separate deliveries per location/cost centre OR consolidated delivery?"
Clarification: ASM contacts client BEFORE SO creation: "Your 3 POs are per cost centre. Do you want: (a) Single consolidated delivery to HQ (saves ₹X delivery cost), OR (b) Separate deliveries to each cost centre location?"
If separate deliveries needed: ASM creates separate SOs per delivery location (not per PO, but per delivery address); invoice can still reference all relevant PO numbers
If consolidated delivery: ASM creates single SO; confirms delivery address; client internally distributes items per cost centre after receiving consolidated shipment
SO documentation: Delivery instructions clearly state: "Consolidated delivery for CC-101, CC-102, CC-103 to [Address]" OR "Separate deliveries: CC-101 to [Address A], CC-102 to [Address B], CC-103 to [Address C]"
Client communication: ASM sends delivery confirmation email: "Your order is being delivered as follows: [Details]. If this doesn't match your expectation, please inform us within 24 hours before dispatch"
If confusion after delivery: Pod Lead apologizes; offers to redeliver sorted per cost centre at company expense (if items not yet distributed); waives redelivery charges
Future orders: Client delivery preference saved in CRM; ASM follows saved preference for future multi-PO orders
Escalation Matrix — Who to Contact When
Issue Type Timeline First Contact Escalation
Feasibility check required Before quote creation Shant / Manju Pod Lead (if no response in 4 hours)
Quote approval Same day as creation Pod Lead N/A (Pod Lead is final authority)
Quote extension request (Day 7) Before quote expiry Pod Lead (ASM requests approval) MD (if client has history of >2 extensions without PO)
Size data not received Day 7: Follow-up
Day 14: Escalate
ASM weekly follow-up Pod Lead contacts client decision-maker
Amendment after SO sent Within 2 hours Balu (Procurement) Pod Lead (if vendor impact unclear)
Rush order feasibility Within 1 hour Balu (Procurement) for inventory Pod Lead for approval
Rush apparel order (standard pack) Before quote creation Balu (confirm standard pack availability); ASM explains constraints to client Pod Lead (if client requests exception to standard pack policy)
Rush apparel: custom ratio request Within 2 hours of request; before quote creation Balu (verify ALL sizes in stock); Pod Lead (approve if feasible) N/A (requires DUAL approval; both must agree or custom ratio rejected)
Rush apparel custom ratio: size out of stock after quote Within 1 hour of discovery Pod Lead (immediate client contact) MD (if reserved stock was improperly released to another order)
Rush apparel: client late with size data (>2 hours) At 2-hour mark ASM switches to standard pack; informs client Pod Lead (can grant 1-hour extension for high-value orders >₹50k)
Rush apparel: client requests size exchanges post-delivery Immediately upon request ASM refers to written confirmation; offers future discount Pod Lead (if client escalates or threatens relationship damage)
Stock order creation Before order placement E-commerce Manager (<₹50k auto); Pod Lead (₹50k-₹2L); MD (>₹2L) Finance (if budget concerns); MD for final approval on large orders
Stock order: slow-moving inventory (<2 sales/month for 3 months) Monthly inventory review E-commerce Manager (clearance sale decision) MD (if write-off >₹25k or donation required)
Stock order: defective stock received Within 24-48 hours of delivery Inventory Manager (vendor escalation) Pod Lead (if vendor unresponsive); MD (if loss >₹50k)
Stock order: stockout during peak demand Immediately upon detection E-commerce Manager (emergency sourcing) MD (approval for premium sourcing above budget)
Stock order: low margin product (<30%) Quarterly margin review E-commerce Manager (pricing strategy) Pod Lead (discontinuation decision if margin <25%)
Client payment delay Invoice overdue by 7 days Accounts Pod Lead + MD (if >30 days overdue)
Vendor delivery delay Immediately upon notification Balu (Procurement) Pod Lead informs client; negotiates timeline
Quality issue post-delivery Within 24 hours Pod Lead Balu coordinates replacement; MD if major escalation
ASM unsure of scenario classification Before quote creation Pod Lead IT Division (for process clarification)
System/Zoho technical issue Immediately IT Division (R Roger Daniel Fernando) External Zoho support (if unresolved in 4 hours)
Add-on order request (SO-2 creation) Before SO-2 creation ASM validates with Balu if vendor PO sent Pod Lead (if add-on >₹50k or introduces new products); MD (if total inquiry value >₹5L)
Add-on order: vendor PO amended in error Immediately upon discovery Balu contacts vendor to issue corrected PO Pod Lead (if vendor confusion; process review required); MD (if vendor threatens relationship)
Add-on order: delivery coordination mismatch Before delivery date Balu coordinates separate deliveries with vendor ASM (if client expectation of combined delivery); Pod Lead (if client escalates dissatisfaction)
Add-on order: multiple add-ons (>2 requests) Upon 3rd add-on request ASM suggests creating new inquiry for better tracking Pod Lead (exception approval for high-value clients >₹2L); MD (if exception value >₹5L or operational chaos)
Email approval order (Scenario 14): creation request Within 1 hour of email receipt Pod Lead (MANDATORY approval required; validates 4 email requirements) N/A (Pod Lead must approve ALL email-only SOs; no delegation)
Email approval: PO not received after 7-day deadline Day 7 + 48 hours grace period ASM follows up daily; Pod Lead contacts client on Day 5, 6, 7 Balu (HALT production on Day 9 if no PO); MD (if client relationship critical and WIP >₹1L)
Email approval: client disputes authorization later Immediately upon dispute Pod Lead (reviews email evidence; contacts client with documentation) MD + Legal (if client refuses payment; threatens legal action)
Email approval: value mismatch (email says ₹X, final PO says ₹Y) Within 2 hours of PO receipt ASM flags to Pod Lead; holds SO processing until clarified MD (if client insists on lower PO value; threatens to cancel order)
PO structure mismatch (Scenario 15): client expects SOs to mirror PO structure Before SO creation; proactive communication ASM explains deliverability-based SO logic to client contact; references Scenario 15 documentation Pod Lead (if client contact insists on PO-matching SOs); Finance + MD (if client CFO escalates invoice mapping concerns)
PO structure: finance department confusion on PO-invoice mapping Before invoice generation Accounts (coordinates with client finance; explains mapping: 1 inquiry → multiple POs → multiple SOs → invoices reference all PO numbers) Pod Lead (provides Scenario 15 documentation to client finance); MD (if client threatens payment hold due to PO-invoice mismatch)
PO structure: ASM creates SOs matching PO structure (error) Immediately upon detection (Procurement review) Procurement flags to Pod Lead; ASM cancels incorrect SOs Pod Lead (retraining on Scenario 15; ASM creates correct deliverability-based SOs); MD (if error caused client confusion or delivery delays)