# Self Attempt 01 > MedBridge Sales Ops SOP - Skill: `prism-shadow/self-attempt-01` (Agent Skill) - Install (CLI): `npx skillmds@latest add prism-shadow/self-attempt-01` - Raw SKILL.md: https://api.skillmd.com/api/skills/prism-shadow/self-attempt-01/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: prism-shadow (https://skillmd.com/u/prism-shadow) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/prism-shadow/self-attempt-01 --- # MedBridge Sales Ops SOP Use this skill for MedBridge Sales Ops tasks that ask for quote/RFQ reconciliation, freight options, account milestone status, invoices, payments, revenue recognition, events, or vouchers. ## API workflow - Use the environment note for the base URL. Sanity check with `GET /health`, then inspect `GET /api` if endpoints are uncertain. - Public collections: `/api/customers`, `/api/products`, `/api/rfqs`, `/api/quotes`, `/api/freight-quotes`, `/api/policies`, `/api/opportunities`, `/api/invoices`, `/api/payments`, `/api/revenue-journals`, `/api/events`, `/api/vouchers`. - Most collections also support `GET /api//` where listed by `/api`; otherwise fetch the collection and filter locally. - Use `/api/search?q=` for ambiguous customer names, product names, quote IDs, RFQ IDs, contacts, event names, or voucher codes. Treat search as discovery, then verify against the canonical collection record. - Pull policies early. They define payment terms, quote scope, freight validity, module granularity, quote validity, EXW exclusions, and revenue recognition. ## Source precedence - Exact ID in the task beats search results. If an ID is not given, prefer exact name/contact/product matches over fuzzy matches. - Current commercial records beat older planning records: prefer RFQs with active working statuses such as `open`, quotes with `revision_requested` or `advisory_requested` when the task is about active revisions, and closed/won opportunities when the task is about service delivery. - Ignore or clearly label records with `draft`, `superseded`, `archived`, `closed_lost`, `stale`, or `mismatch` unless the question explicitly asks about them. - For quote revisions, use the current `confirmed_quantity` or line-level `confirmed_quantity`; prior quantities and prior prices are historical context only. - Product catalog `price_tiers` override prior quote prices and benchmark notes. Choose the tier where `min_qty <= quantity` and `quantity <= max_qty`, treating `max_qty: null` as no upper bound. - Module RFQs should stay at module/bundle line level. Do not price components from composition notes unless the customer explicitly asks for component-level pricing. - Customer payment profile is useful context, but policy rules override it when applicable, especially new NGO prepayment and recurring NGO net terms. ## Quote and RFQ reconciliation - For each requested line, join RFQ/quote `product_code` to `/api/products`. - Quantity source order: line `confirmed_quantity`, quote `confirmed_quantity`, line `requested_quantity`, RFQ `requested_modules[].quantity`. - Calculate `unit_price_usd` from the selected catalog tier. Calculate `line_total_usd = quantity * unit_price_usd`. - Carry product `unit`, `lead_time_days` or `lead_time_weeks`, `weight_kg`, `cbm`, and `cold_chain_required`. - Shipment totals are normally `sum(quantity * product.weight_kg)` and `sum(quantity * product.cbm)` unless an attached freight quote provides the shipment metrics to use. - For indicative RFQs without a confirmed destination, quote EXW only and exclude freight. Include EXW exclusions: freight, insurance, import duty, customs clearance, and last-mile handling are not included unless separately offered. - For module requests, consolidate repeated module quantities when the RFQ narrative says to consolidate. Do not split sachets, kits, or components out of a module. ## Freight handling - Join freight options by `freight_quotes.quote_id == quote.id`. - Use only options with `status: active` unless the user asks to discuss stale/mismatched options. Exclude `stale` and `mismatch` from recommended pricing. - Check `valid_until`; freight is valid only through that date and must be reconfirmed at final order. - Preserve freight as separate optional lines when the incoterm is `EXW plus freight options`; do not roll freight into the EXW product subtotal unless asked for a delivered total. - Include `mode`, `forwarder`, `cost_usd`, `transit_days_text`, `route_risk`, `risk_notes`, `valid_until`, and cold-chain support when relevant. - If any product requires cold chain, verify freight `cold_chain_support`; flag non-supporting options instead of silently recommending them. - For grant or need-by timing, compare product lead time plus freight transit range against the stated need-by date. Prefer transparent risk notes over overconfident pass/fail claims. ## Account, invoice, and revenue tasks - Join `opportunities` to `customers`, then phases to `invoices` by `invoice_id` and `phase_id`. - Join invoices to `payments` by `invoice_id`; use posted payments to verify paid status and payment date/reference. - Join revenue by `revenue-journals.invoice_id` or `phase_id`. - Revenue recognition rule: when a milestone is complete and paid, verify or create recognition from Deferred Revenue to Implementation Services Revenue. Paid complete milestones without a posted revenue journal are missing recognition. Unpaid future milestones stay outstanding. Due or overdue unpaid invoices drive collection follow-up. - Treat `proposal`, `negotiation`, and draft invoices as distractors for won-account revenue recognition unless the task explicitly asks about pipeline/proposals. - Use invoice `status`, `due_date`, `paid_amount_usd`, and `outstanding_amount_usd` together; do not infer paid/overdue from one field alone. ## Events and vouchers - Join events to vouchers by `events.voucher_code == vouchers.code`, and also verify matching `customer_id` and `opportunity_id`. - Report event `status`, `event_date`, `primary_contact`, `follow_up_owner`, and voucher `discount_percent`, `max_redemptions`, `redemptions_used`, `valid_until`, and `status` when asked for follow-up readiness. - Expired, completed, tentative, or nonmatching event/voucher records should be labeled instead of mixed into current active recommendations. ## Output conventions - Follow any requested schema exactly. If none is specified, use a compact table plus short notes. - Preserve API identifiers exactly: `customer_id`, `product_code`, `quote_id`, `rfq_id`, `invoice_id`, `phase_id`, `event_id`, and voucher `code`. - Money is USD unless a record says otherwise. Use two decimals for calculated amounts and keep freight separate from catalog/product subtotals. - Dates should be ISO `YYYY-MM-DD`. Quote pricing is valid for 30 calendar days from `quote_date` unless overridden; freight validity uses each freight quote `valid_until`. - Status words should come from the API when possible. If adding an interpretation, make it explicit, e.g. "action: collect", "risk: stale freight", or "recognition missing". - Include concise source notes for non-obvious decisions: tier selected, stale/mismatch freight excluded, EXW exclusions, payment-term policy, or revenue-recognition gap. ## Common traps - Component composition arrays and narrative component lists are usually distractors for module quotes. - Prior quantities, prior unit prices, older benchmarks, and superseded RFQs should not override current quote/RFQ quantities or catalog tiers. - Freight quotes can share a quote ID but still be stale, mismatched, wrong-size benchmarks, or distractor routes; filter by status and reasonableness. - New NGO/prospect accounts generally need prepayment policy treatment even when the customer profile says review. - EXW does not include freight or import/delivery costs; "EXW plus freight options" means separate optional freight. - Paid invoice does not automatically mean recognized revenue; verify a revenue journal for each complete-and-paid milestone. - Open proposals and draft invoices are not closed-won revenue obligations unless the task asks about pipeline.