Speaker Notes
SLIDE 1 — Opening
Priyanka opens with the DevRev company overview: founders, team. Keep it brief, just enough to establish credibility before moving into product.
Handover: Priyanka hands over to Shreeraj for the architecture section next.
SLIDE 2 — About DevRev
Presenter: Priyanka. Credibility slide: founders (Nutanix pedigree), funding, scale, then the customer wall and impact numbers.
Key points:
• Dheeraj Pandey led Nutanix to the biggest tech IPO of 2016; sits on the Adobe board.
• $250M+ raised, $1.15B valuation, 1,000+ enterprise customers.
• Customer wall lands the India relevance: HDFC Bank, ICICI, Paytm, Razorpay, Jio Financial, plus NVIDIA and S&P Global for global weight.
• Compliance chips (SOC 2, ISO 27001, India DC) pre-empt the security question before the dedicated slides later.
SLIDE 3 — Meet the Team
Presenter: Priyanka (or Neeraj). Quick, warm slide — this is the team Strides will be working with (not everyone is in the room). One line per person, then move on. Don't read the cards.
Key points:
• Neeraj: The leader of this engagement — building DevRev's India business from the ground up. 25+ years taking category-defining tech to market: ran AWS's Digital Natives business (India's fastest-growing companies), took Dell storage from nowhere to No. 3 in India, 13 years at HP rising to Country Manager. Strides gets his direct ownership.
• Murali: Head of Solutions Engineering, India. The Nutanix connection made personal — he built Nutanix India from scratch as its first engineering director, scaled 5 → 120+ engineers behind 2016's biggest tech IPO. Ties directly back to the previous slide's "team behind Nutanix" claim.
• Priyanka: IIT Kanpur, Microsoft manufacturing sales, a decade owning automotive/manufacturing accounts — she speaks Strides' language.
• Rahul: ex-PwC Senior Consultant; co-founded an Amazon-certified conversational-AI agency, built voice AI for Honda, Maruti Suzuki & Hyundai.
• Shahabaj: built IndiGo's most successful AI agent — works autonomously across 4 enterprise systems with 90%+ adoption. 14 years riding each wave of automation (RPA → ML → AI agents), including a $4.2M/yr optimizer. The person who will architect Strides' agents.
Land the closing line: this isn't a sales team that hands off after signature — this is the dedicated team that delivers for Strides.
SLIDE 4 — Security & Data Protection (combined)
Segue in: "Before we show you what we've built — why do large enterprises, including financial institutions, trust us with their data?" Walk the rings from the inside out: Strides' data at the core, five layers around it.
Layer 1 — Encryption: AES-256 at rest, TLS 1.3 in transit, per-org unique keys — even within our infrastructure, Strides' data can't be decrypted with another customer's key.
Layer 2 — PII: emails, phones, cards, gov IDs caught before they're stored, masked on write, masked again when AI surfaces content.
Layer 3 — Isolation: every API request carries a JWT scoped to Strides' org; queries physically scoped at the DB layer; Istio mTLS Zero Trust between services.
Layer 4 — Access & audit: no DevRev engineer can see Strides' data by default; emergency access is approved, time-limited, audited; logs 7+ years, exportable to their SIEM.
Layer 5 — India boundary: AWS Mumbai (ap-south-1); processing, storage, backups, DR all in-region. Done before for BFSI customers needing RBI localization.
The red strip: "DevRev does not train any AI model on your data. Full stop. Contractual ZDR with OpenAI, Anthropic and Google."
If asked how to verify: DPA states it explicitly; security.devrev.ai has the SOC 2 report and ISO bridge letter.
If asked physical vs logical separation: logical at the app layer with per-org keys; dedicated-VPC can be discussed separately.
Closing line: "Security isn't a bolt-on. We serve NVIDIA, S&P Global and several Indian BFSI enterprises on these same controls." Then: "Now let's look at the architecture all of this protects."
SLIDE 13 — Computer Architecture (interactive walkthrough)
This is a click-through build. Each click/→ reveals one step — pace it to the room, and skip ahead with → if pressed for time.
The sequence:
1. Base flow: every department's tools (Product, Engineering, Sales, Support, Finance, IT&HR + Communication) sync 2-way into the Knowledge Graph via AirSync.
2. Data Warehouse → Summarization Jobs → Time-Series Analytics reveal (with tooltips), then the 360° views fan out.
3. Enterprise Search: one graph, three ways to search — syntactic, semantic, text-to-SQL, per department. (Click the pulsing arrow to reveal the hidden columns.)
4. Computer demo: two product videos (single-player + multiplayer). Use "Skip" in the search overlay if short on time.
5. Workflow Engine → Agent Studio takeaway.
6. Marketplace: AirSync connectors, MCP, hosting.
7. Customer apps (chat widget, search bar, session replay, portal, voice AI) → internal apps (Support / Build / Grow) — all wired to the same graph (RAG + actions).
8. Final takeaway: One platform. One architecture. Then the full diagram, then the next slide.
Land the point: everything Strides just saw runs on one Knowledge Graph — connect once and it all compounds. "Because of this architecture, look at the kind of enterprise use cases we're solving..."
SLIDE 5 — Use Cases Overview (hub-and-spoke, 2-step build)
This opens the use-case section — the room sees every Strides function around one platform before any deep dive.
Step 1 (→): the six functions draw in around the DevRev core. Say: "Here is where DevRev applies across Strides — manufacturing, energy, procurement, sales, HR & IT, engineering. One platform underneath all six. We'll show you the use cases first, then open up the architecture that makes them possible."
Step 2 (→): five spokes light up with DEEP DIVE chips, the last one dims. Say: "Five of these, up close — over the next five slides. The rest we'll cover briefly, and every one of them has full detail in the appendix."
The breadcrumb at the bottom shows where we are in the journey: team & company done, security done, use cases now, architecture and requirements discussion still to come. Use it to set expectations for the remaining time.
SLIDE 6 — Proposal & Bid Automation (1/5, 2-step build)
Step 1 (→): the five source types on the left feed the blue Extraction Agent, which populates the Knowledge Graph — watch the five satellite nodes (Requirements, Components, Cases, Sections, Images) attach. Say: "Your best proposals stop being files in a folder and become structured memory."
Step 2 (→): Computer’s generation stack lights up and sector-ready outputs fan out on the right — PPT, DOCX, PDF per vertical. The point: a first draft in hours, every claim traceable to something you actually won.
Customer context (do NOT name on the slide): this is in POC with PwC India — their Data & Analytics practice, Retail & Consumer vertical first, 25–30+ anonymized proposals, 4-week pilot, production targeted at a dedicated VPC in their own cloud. On the slide we say "a Big Four consulting firm in India."
Why first for Strides: Strides lives on tenders and bids — steel supply contracts, infrastructure bids, energy PPAs. Same pattern: past bids → knowledge graph → grounded first drafts. It also quietly demos the platform’s core USP (the knowledge graph) before the architecture slide.
SLIDE 7 — ITSM: Employee Offboarding (2/5, 2-step build)
Build: step 1 (→) reveals the detection pipeline; step 2 (→) closes the doors (access revocation) and lands the audit-trail impact strip with the 100% counter.
Position this as non-trivial ITSM — explicitly distinct from commodity password-reset and hardware-request automation. Say: "This isn't the easy stuff. This is the use case where getting it wrong shows up in an audit finding."
Lead with the audit angle: orphaned accounts are one of the most common SOC 2 and ISO 27001 findings. The platform's value is the timing precision: not revoking access too early (legal exposure) or too late (security exposure), plus a complete audit record of every system revoked, when and by what rule.
Land it on Strides' context: at a large industrial enterprise with many managers and contractors, a departing manager's permissions and the accounts/systems they own are a real operational risk. That's the pain point to probe for in the room.
SLIDE 8 — Procurement Negotiation (3/5, 2-step build)
Build: step 1 (→) reveals the negotiation corridor, metric cards and claims table; step 2 (→) reveals the two bottom capability cards.
Presenter: Shreeraj. Real customer context (keep private, generalized on slide): this is Blue Star's procurement team negotiating rotary compressor pricing with GMCC (Guangdong Meizhi Compressor Limited). The ₹9.5 Cr projected saving and the 4%, 3% and 1.9% corridor are real numbers from that engagement, anonymized on the visible slide to "a major appliance manufacturer" and "their supplier." The competitive intelligence example (import volumes collapsing as a competitor shifts to local manufacturing) comes from a separate rotary-compressor market intelligence report also built for Blue Star. Pitch to Strides: this is not appliance-specific. It's a generic procurement negotiation and market-intelligence capability, and Strides' steel, auto and energy divisions run large, recurring supplier negotiations (iron ore, coking coal, components) that are exactly the kind of high-stakes, repeatable negotiation this pays back on fastest.
SLIDE 9 — Solar Energy Forecasting (4/5, 2-step build)
Real customer context (private): built with a major energy consultancy for solar operations (PwC engagement). NOT live in production yet — do not offer customer references or meetings. The 94% accuracy, 40-60% DSM reduction and 6-week build numbers come from that engagement's validation, framed on the slide as "problem definition to solution."
Key talking points:
• "This is not a chatbot or a ticket system. It's an AI platform that ingests IoT data from physical assets, trains ML models on your operational history and deploys agents that act on predictions."
• Emphasize the design principle: the ML layer is fully deterministic and auditable; the Gen AI agent never invents numbers, it only interprets and acts on what the ML layer already computed. This directly pre-empts Strides' "will it hallucinate on production data" concern.
• Map directly to Strides Energy's solar assets. This is a like-for-like replication opportunity, not a hypothetical.
If asked about other equipment types: "Swap solar SCADA for conveyor belt or plant IoT sensors. The same cross-correlation engine works on vibration, temperature or material flow data. This is exactly the bridge into the manufacturing quality slide next."
Build: step 1 (→) reveals the three-layer flow; step 2 (→) lands the four metric cards (94% counter) and the design-principle strip.
SLIDE 10 — Manufacturing Quality Root Cause (5/5, 2-step build)
Framing discipline (important): this is a capability on the proven pattern — the same architecture as the energy solution on the previous slide (not yet live in production either — see that slide's note) — not a claimed steel deployment. Say: "Everything you just saw on the energy side, applied to a quality problem." Do not imply we have this running at a steel plant today.
Build: step 1 (→) reveals the 4-step agent chain (detect → correlate → pinpoint → act) and the correlation trace; step 2 (→) lands the verdict card and the benefit band.
The story: a surface-defect spike on finished coils. Process parameters (caster mold temperature), sensor telemetry and lab/QC results already live in the same knowledge graph — the agent correlates them and names the cause: Caster 2, a mold-temperature excursion in a specific time window, specific heats. Then it acts: 42 downstream coils from those heats flagged and held before dispatch.
Benefits to land: root-cause analysis from days to hours; fewer rejections and rework; fewer customer quality claims because affected material never ships.
If asked "is this failure prediction?": no — the predictive maintenance capability is in the appendix. This is about catching the defect AND its root cause, which needs cross-source correlation, not just anomaly detection.
SLIDE 11 — Other Use Cases (one-liners, no build)
Keep this fast — 60 to 90 seconds. Six more proven capabilities, one line each: incident management (75%+ MTTR), demand forecasting, predictive maintenance, employee onboarding, support at India scale, SDLC on one graph.
The point to land: "We picked four to go deep on today, but the platform doesn't stop there — full detail on every one of these is in the appendix, and we're happy to go deep on any of them right now if one catches your eye." Watch the room: if someone leans in on a specific row, offer to jump to its appendix slide live.
SLIDE 12 — Case Studies: Razorpay + Paytm (one slide)
Presenter: Shreeraj. One slide, two proof points, one message: the same platform runs the full spectrum — left side is Build (engineering & product), right side is Support at India scale. The DevRev node in the center spine is the visual anchor: say "every use case you just saw, and both of these customers, run on one platform — and next, we open it up and show you the architecture inside."
Razorpay (left): one of India's largest fintech players. 1,600 cross-functional users on one source of truth. Lead with the red 60% — most dev ran outside sprint cadence and velocity was never measured; now Dev360 dashboards (DORA + SPACE) put real velocity data behind every decision. Strides' requirements ask about observability dashboards — this ties straight into the requirements slides later.
Paytm (right): the scale proof. 700M+ users, 6M tickets/month, 1,500+ agents on a single instance. The Freshdesk migration strip (30M+ objects, 4,000+ workflows, 2,000+ macros, 30+ integrations) is the answer if Strides raises migration-risk concerns. The 200+ → under-75 ticket-fields pill is platform-driven simplification, not automation layered on complexity. Build-vs-buy was settled in favor of buy.
Land the bottom band: one source of truth, build-vs-buy settled, AI-native scale without headcount.
Presenter: Shreeraj. (3-step build — one bucket per →.)
What you asked for, distilled into three buckets: 1) individual productivity — a chat interface every employee can use (absorbs part of the model-flexibility ask); 2) enable builders — low-code/no-code Agent Studio so Strides' own teams build agents; 3) security & no data leakage — absorbs DLP and the rest of model flexibility. Each bucket shows "your ask" in their words, then what DevRev provides. The IoT requirement is reframed on the closing line as connecting across all enterprise applications — SAP, SCADA, mail, ITSM — through one knowledge graph.
This slide is a springboard for discussion, not a conclusion. Frame it exactly as: "This is our understanding. Can we discuss the use cases you had in mind behind each of these?" The goal is to surface the real intent behind the requirements document, which may have been drafted by consultants and not fully reflect what the Strides team actually needs day to day. Don't defend DevRev's interpretation of the document — use it as a prompt to get Strides talking about the underlying use case behind each line item.
Note: UAT-to-production promotion was intentionally left off this summary. It's a real requirement and will be addressed, but handle it separately in the discussion rather than presenting it as one of the buckets here.
SLIDE 15 — Platform Depth (wow factor, 2-step build)
Framing (updated): Strides has NO intention to build this themselves — so this is not a build-vs-buy scare slide. It's a depth-and-credibility slide: "here is what a platform like this is made of, and why it took us four years and 800+ people to build it." The left stack shows the ten systems INSIDE DevRev, not a to-do list for Strides' team.
Build: step 1 (→) piles up the stack box by box — data pipelines, vector DB, embeddings, orchestration, auth/RBAC, evals, monitoring, connectors, prompt management, cost controls — then the wiring. Say: "every box is a product in its own right; every wire is an integration we engineered and hardened." Step 2 (→) lands the right side in one beat: all of that depth as one product — Paytm live in 8 weeks.
The one line: "That's the difference a knowledge graph makes." Azure AI Foundry and Vertex AI hand you components; four years of engineering turned those components into a product. The 8-week number is the real Paytm go-live — 30M+ objects, 4,000+ workflows migrated — not a hypothetical.
If they ask "why can't a system integrator assemble this for us?": the boxes can be assembled; the graph relationships, evals and hardening between them are the four years. That glue is the product.
SLIDE 16 — Status & Roadmap (closes the presentation)
CLOSING INTO DISCUSSION:
Presenter: Shreeraj, facilitating. The full team contributes from here.
This slide closes the presentation portion and opens live discovery discussion. At least 50% of the total session time should go here.
Discovery questions to have ready:
1. "When you put together these requirements, what use cases were at the back of your mind?"
2. "If you're using AI today, where is it working well and where are you struggling with adoption?"
3. "What teams or departments do you think AI can have the biggest impact on?"
Listening rules: never negate anything Strides says. If they claim something is already working well, respond with "That's great to hear — we can look at opportunities for further optimization," not a correction. Let them finish speaking before responding.
SLIDE 17 — Thank You (discussion backdrop)
Leave this slide on screen for the entire discussion — the three questions on it are the discovery questions, visible to the room so Strides can react to them directly.
Presenter: Shreeraj facilitating; the full team contributes. Same listening rules as before: never negate what Strides says; if they claim something already works well, respond with "That's great to hear — we can look at opportunities for further optimization." Let them finish before responding.
If the discussion calls for detail on incident management, demand forecasting or predictive maintenance, jump forward into the appendix (→).
APPENDIX DIVIDER
Presentation ends before this slide. Everything from here is backup detail — jump in only if the discussion calls for it. Do not present the appendix linearly.
APPENDIX — Incident Management
Same pattern as offboarding, different trigger: an event (here, a monitoring alert) kicks off a multi-agent pipeline, with a human-approval gate on the risky steps. Make that parallel explicit if the audience is engaged. It reinforces that this is one platform pattern, not a one-off feature.
Lead with the noise-reduction hook: 500 events collapsing into 1 correlated incident (90%+ noise reduction) is the concrete before/after that lands with an ops audience. Follow with the business-impact number: 75%+ MTTR improvement.
Autonomy framing matters to a skeptical infra buyer: be clear that low-risk remediation (service restart) runs autonomously, while anything higher-risk (firmware, topology changes) stops at a human gate. Everything is logged. The service-degradation example is from DevRev's own internal operations (we do not have MELTS deployed at a customer yet) — a good concrete anecdote if asked "what does this actually look like," but do not present it as a customer deployment.
APPENDIX — Demand Forecasting (2-step build: → agent chain, → forecast band + stats)
Presenter: Shreeraj. This is proven with Tata Motors: demand forecasting and sales scoring for their automotive/EV business. Maps directly to Strides' MG Motors joint venture: Strides holds the majority stake, 500,000+ MG vehicles are already on Indian roads, and the dealer network runs through a DMS just like this architecture ingests. Flag for the room: Tata Motors asked the exact same question that's sitting in Strides' requirements: "can we host our own model and pick our own GPUs?" The answer is identical either way: training happens outside DevRev, on their infrastructure, with their data; DevRev's workflow layer just calls the external endpoint for inference at runtime. We are not a training/GPU platform. Use the SQL-first knowledge graph point to preempt any "isn't this just an LLM guessing" pushback. Walk through the token efficiency number (60-80% fewer tokens vs raw LLM+MCP) if asked how this scales cost-wise.
APPENDIX — Predictive Maintenance (2-step build: → signal chain + temp curve, → catch point + savings band)
Presenter: Shreeraj.
Real customer context (private, do not say the name on slide): this capability is proven, drawn from an industrial IoT deployment referred to internally as "N Rail." The bearing-failure and wind-turbine-gearbox examples are real illustrative scenarios from that engagement, generalized here as "heavy machinery" and "renewable asset" for the visible slide.
Positioning for Strides: map this directly to steel-plant rotating equipment: compressors, motors, conveyor systems, mill drives. Unplanned downtime on this class of equipment is expensive, and the sensor data already exists in their SCADA/DCS/MES stack, so this isn't a new instrumentation ask. It's a new brain sitting on top of data they already collect. Emphasize the "auto-verify readiness" step (spare part, engineer, safe window) as the differentiator versus a plain alerting/monitoring tool. Most vendors stop at the alert; this platform gets to "action taken" before a ticket even exists. If asked about model training: it uses ML models trained on their own equipment/failure history, combined with Gen AI for the semantic pattern-matching and orchestration, not a generic off-the-shelf model.
Build & SDLC
Support at Scale