| 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 |
| 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 |
| 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) |