{"text": "many moved to the right", "label": "positive", "surface": "thread_reply", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "Autonomous agent is up and running and the team legitimately thinks it's me, it's pinging asking for updates on tickets (hey i saw W so i moved X, did you ask about Y? Can we do Z?) and they're all responding to me in slack lol", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "Only super apparent advantage is speed of availability of transcripts, but how often do you need a call transcript 2 minutes after the call, really. ~30 minutes (gong standard) is acceptable", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "Agreed. Let's just add acknowledgement that it's been passed to advocacy", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "there may be a better way to do this; case studies take a while, so just ensuring that advocacy knows about it and has been engaged is probably the better solution here", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "For ECS, it can resolve from a few other places; gateway isn't the only thing it does", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "list_customers has three modes:\n(a) search by name\n(b) assignee_email + optional assignee_role for portfolio lookup\n(c) list all", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "Don't see any mention of a team-locked Enterprise App on here, has it been explored?", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "Hey, chatted with Sam and Zak on this this morning, just closing the loop -- all the tokens were nulled-session test tokens to begin with aside from the postman API key. There was never a Cloudflare API key in there; the cloudflare worker used a Postman API key for auth to assert membership to a given Postman team and otherwise gate access to the proxy", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "I'd just put what you mentioned above in the ticket and mention this has already been reviewed/preliminarily approved by @john.offenhartz and myself. Should be all you need", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "Approved to get a resource assigned. This should be something CSE can handle in the future, but we still don’t have any CSE resources hired, so need to cover the gap in the meantime", "label": "positive", "surface": "jira_standalone", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "Deal. Sounds good to me.", "label": "positive", "surface": "thread_reply", "topic": "on", "source": "examples", "generator": "human", "mimicry": false}
{"text": "Thanks Zac; good callout -- the more we can unify on this message to Enterprise customers, the better. Just a few examples of the types of responses we get from customers when we talk about codifying and integrating everything: [list good customer side quotes from calls or slack messages or jira ticket testimonials, only ones CONFIRMED to be from customers and NOT postman employees]", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "examples", "generator": "human", "mimicry": false}
{"text": "Hey @[Adrian] + @[Andrew], where are we at with these guys? Assuming we got them bumped to v12, do we have a discovery followup scheduled to see if we have a real engagement to dive into?", "label": "positive", "surface": "jira_standalone", "topic": "on", "source": "examples", "generator": "human", "mimicry": false}
{"text": "Marked Exec Sponsor as Tej Chadha, VP Platform Eng. @alex does that track?", "label": "positive", "surface": "jira_standalone", "topic": "on", "source": "prose-voice", "generator": "human", "mimicry": false}
{"text": "Setting Technical Counterpart to Kristin Colbert, Test Automation Manager -- @jane any objection?", "label": "positive", "surface": "jira_standalone", "topic": "on", "source": "prose-voice", "generator": "human", "mimicry": false}
{"text": "I'm not sure who we want as Exec Sponsor here. SF names Dileep Kovela, but he hasn't shown up in recent project comms. @mike is he still the move?", "label": "positive", "surface": "jira_standalone", "topic": "on", "source": "prose-voice", "generator": "human", "mimicry": false}
{"text": "Foot Locker asked for a v12 migration follow-up on the call, but I don't see one attached here. @andrew do we have that scheduled or should we park this?", "label": "positive", "surface": "jira_standalone", "topic": "on", "source": "prose-voice", "generator": "human", "mimicry": false}
{"text": "Hey @hammad, Jeremy hasn't answered the last two pings and there's no blocker noted here. Should we push one more note over or move it to blocked?", "label": "positive", "surface": "jira_standalone", "topic": "on", "source": "prose-voice", "generator": "human", "mimicry": false}
{"text": "Hey @adrian + @andrew, looks like we got these guys bumped to v12. Do we have a discovery follow-up scheduled to see if there's a real engagement here?", "label": "positive", "surface": "jira_standalone", "topic": "on", "source": "prose-voice", "generator": "human", "mimicry": false}
{"text": "Hey @andrew, can we pull some time together with the account team to game plan on this one? Not sure we've had the full story pitched to them; there's opportunity here, just need to figure out how/when to deliver the narrative with the team.", "label": "positive", "surface": "jira_standalone", "topic": "on", "source": "prose-voice", "generator": "human", "mimicry": false}
{"text": "i was calling it Mr Clean", "label": "positive", "surface": "thread_reply", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "Thinking about AEs seeing what's happening in their accounts", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "Not just as an activity record?", "label": "positive", "surface": "thread_reply", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "we basically just need:\n1. Silent transcriptions\n2. Transcriptions stored in a system with a good API/MCP", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "- this engagement has been approved. shouldn’t this be in the discovery stage?", "label": "positive", "surface": "jira_standalone", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "This document is meant to provide clarity for anyone assigned to a Tier 1 customer. If you are assigned to an account, this is the playbook. It should tell you what we are trying to accomplish, how we are going to accomplish it, what you are expected to do, what tools are available to you, and how we will measure success. Once you are assigned to an account, you are accountable for creating forward motion. You are not expected to know everything on day one. You are expected to quickly understand what we know, identify what we do not know, and build a plan to close the gaps. Your job is to help customers compress time to value, drive adoption of sticky use cases, and deliver customer insights back to the business.", "label": "positive", "surface": "longform", "topic": "on", "source": "confluence-charter", "generator": "human", "mimicry": false}
{"text": "EMs should be especially proactive in helping the account team get wider and higher, engage the right people across the account, and surface use case opportunities. CSEs should help identify technical gaps, shape the technical point of view, and support stakeholder conversations where their expertise adds credibility. Once the right stakeholders are engaged, CS owns turning their desired outcomes into actionable success plans, activated use cases, and documented impact. Regardless of our role, we strive to know our customers inside and out.", "label": "positive", "surface": "longform", "topic": "on", "source": "confluence-charter", "generator": "human", "mimicry": false}
{"text": "Excellence will not happen overnight. Your first responsibility is to create clarity within your role and identify where we have gaps in our understanding of the customer. If there is no account strategy, help shape it. If there is no stakeholder map, help build it. If the right stakeholders are missing, identify the gap and support Sales in closing it. If we don't know which outcome the customer seeks, help discover one. If there is adoption but no proof, capture it. If there is proof but no executive awareness, help turn it into an Impact Review that we can promote. If the account is stalled, identify the constraint and raise the help needed. Assignment creates responsibility to contribute, make the work visible, and move the account forward. It does not transfer accountability or account ownership away from Sales.", "label": "positive", "surface": "longform", "topic": "on", "source": "confluence-charter", "generator": "human", "mimicry": false}
{"text": "Bad Strategy Shaping is waiting for the AE, the customer, or a renewal event to tell us what matters. The plan is generic. You can describe activity, but not why it matters. Good Strategy Shaping is understanding the commercial objective, current Postman usage, key stakeholders, and likely problems. You have a documented account thesis and a plan to validate it. Great Strategy Shaping is when the account team has a sharp, evidence-backed point of view on how Postman can become critical infrastructure for the customer. You know the business priority, the technical workflow, the owner, the next play, and the revenue implication.", "label": "positive", "surface": "longform", "topic": "on", "source": "confluence-charter", "generator": "human", "mimicry": false}
{"text": "For EMs, this often means deploying a CSE against a qualified problem and keeping the broader customer program aligned. EMs are responsible for spotting the signal, such as a Governance initiative, identifying the owner, and positioning the value of CSE. For CSEs, this means doing the technical work: discovery, scoping, internal proof, customer implementation, validation, and asset creation. Both roles are accountable for making sure activation produces evidence. We may also use teams like Customer Education for large-scale enablement, or Professional Services for large-scale implementations.", "label": "positive", "surface": "longform", "topic": "on", "source": "confluence-charter", "generator": "human", "mimicry": false}
{"text": "Bad Use Case Activation occurs when we just run generic training or answer feature questions in a silo. The customer may be more informed, but Postman is not more embedded. Usage remains relatively commoditized, such as basic API testing. Good Use Case Activation occurs when we activate a scoped use case with an owner, timeline, success criteria, and evidence of adoption. The workflow is useful and the customer confirms value. Postman is no longer just used by developers; engineering leaders are now leveraging the platform to help manage and govern their API operations. Great Use Case Activation occurs when Postman is embedded into an engineering workflow that repeats without CSE involvement. The customer has a runbook or automation pattern they can scale, and removing Postman would degrade how the workflow operates.", "label": "positive", "surface": "longform", "topic": "on", "source": "confluence-charter", "generator": "human", "mimicry": false}
{"text": "Use case activation creates value. Awareness of Impact makes sure that value is understood, validated, and used to drive the next motion. If impact is not visible, it is fragile. Customers reorganize. Budgets shift. Champions leave. Competitors improve. If we cannot explain the value Postman creates in terms the customer cares about, we are exposed. Awareness of Impact is about documenting Postman's current and potential impact, then promoting it through the right channels: case studies, enablement, executive briefings, and Impact Reviews.", "label": "positive", "surface": "longform", "topic": "on", "source": "confluence-charter", "generator": "human", "mimicry": false}
{"text": "We will frequently use these proof points to build our value narrative and validate it with stakeholders. The most common format for this is an Impact Review. Impact Reviews are one of the best opportunities to teach an executive something they did not know about their business. A strong Impact Review should not be a status update. It should connect what we are seeing in the account to the customer's priorities, validate the impact Postman has already made, and prescribe where Postman can deliver even more value. We should be formally reviewing value each time a use case is successfully activated. If it's a smaller win, hosting a smaller Impact Review with our Champions and then sending a 1-page summary to Executive Stakeholders can suffice. If we're running multiple technical tracks in parallel, we can consolidate these wins into a formal Executive Business Review that we host on-site with key stakeholders attending from both sides. If we are not hosting an Impact Review at least once every 180 days, then this is a signal that we are losing momentum with the account.", "label": "positive", "surface": "longform", "topic": "on", "source": "confluence-charter", "generator": "human", "mimicry": false}
{"text": "The reality is that customers struggle to implement workspace topologies, testing frameworks, and governance automation without someone working alongside them through execution. Guidance is not enough. This gap shows up most clearly in IT-driven purchases. IT gets what it needs: SSO deployed, governance controls in place, security requirements met. From their perspective, the purchase is justified. But engineering teams? They're getting the same value they had on the free tier, sometimes less. API definitions stay scattered across cloud consoles, wikis, and institutional memory. Testing remains rudimentary. The engineering problems that the guides are designed to solve remain unsolved.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "Per RFC-139, the core value proposition of an API platform is eliminating the \"discovery tax\" - the hidden cost of engineers spending hours hunting through systems to find APIs. We remove that tax by consolidating a domain's API definitions in Postman. API definitions get imported from Cloud Portals, API Gateways, wikis, and repos. Each collection includes documentation, working auth examples, and lifecycle tags.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "The test: can an engineer find an API in under 30 seconds? Before we show up, that same task takes hours of console navigation and asking around. After, it's a workspace search. We activate multiple test types across the domain: functional smoke tests, auth and error scenarios, integration chaining, and at least one end-to-end workflow. This typically covers 5-10 critical endpoints.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "Tests need to run reliably in local environments before CI integration. The goal is demonstrating that Postman supports meaningful test automation - functional validation, error handling, workflow testing - not just endpoint health checks that return 200 responses. This is a prerequisite to CI integration; only once this outcome is validated do we unlock the ability to meaningfully integrate with CI.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "Advisory model: 3-6 months per domain, because customers are figuring it out on their own between check-ins. Pair programming model: 1-4 weeks per domain, because a CSE is there to guide them through the process. The customer becomes increasingly independent. CSE time shifts from hands-on guidance to validation and spot-checks, and CSMs are free to focus on buying center expansion and renewal strategy.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "Track 2: Domain Pilot CSM coordinates, CSE executes with engineering. Stand up the first Domain API Workspace immediately. Deliver usable value in Weeks 1-4 through co-working sessions. Why run both at once? Because waiting for IT to finish before touching domains adds 3 months to every engagement. Running parallel gives us a domain win while IT work completes, which creates executive confidence and political cover to expand into more domains.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "After Phase 2 - Same test: have them craft a CRUD workflow for a service in the workspace. Time from workspace search to completed workflow. Target: under 30 seconds to find the service, under 5 minutes to set up auth, under 5 minutes to build the workflow.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "What we're doing: Pick at least one visibility channel. CI non-blocking is ideal; tests run on every MR but don't block merges while we stabilize. Monitors can be an alternative, if necessary. Select one high-value, working E2E workflow activated in Phase 3, and integrate it where engineers live: MR/PR comments, Slack notifications, Jira updates, monitor emails.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "If we pass: compile the build log with before/after screenshots and customer quotes, present to the domain lead and exec sponsor, use that proof to open the next buying center. This is how CSMs prospect like AEs - with evidence, not promises.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "What we're doing: Score the domain against the Readiness Scorecard. Address gaps if they exist. Compile the complete build log: before/after, metrics, customer quote. Present to domain lead and executive sponsor to validate value delivered.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "First domains: A single CSE can handle 2-3 first domain implementations across different customers simultaneously (10-15h per domain). This works because the engagement is structured into 4 co-working sessions with customer homework in between, not continuous hands-on work. Second and Third Domains:\\ As customers progress to domains 2 and 3 (requiring 4-6h and 2-4h respectively), a CSE can manage even more accounts. A CSE might be running first domains with 2 customers while supporting second/third domains with 3-4 others. CSE graduation: By the time a customer completes their third domain, the CSE is essentially done with Path A onboarding for that account. They may return later for other work (advanced automation, governance, other use case activation), but the foundational Path A work is complete. CSM longevity: The CSM remains engaged throughout the customer lifecycle - continuing buying center expansion, coordinating additional domains, managing renewals, and orchestrating strategic initiatives. While the CSE's Path A work has a clear endpoint, the CSM relationship is ongoing.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "What tends to succeed: Completing ingestion first, establishing Postman as the primary entry point for API work, then adding automation incrementally while tracking metrics that support renewal conversations. Complete ingestion before moving forward. Without at least 80% of domain APIs in the workspace, subsequent phases build on an incomplete foundation. Engineers continue using their existing discovery patterns (console, wiki, Slack) because those systems still contain the necesasry fundamental information that Postman lacks. Comprehensive ingestion breaks this cycle by making Postman the most reliable source of API information. Early investment in systemic governance and automation can wait until engineers develop the habit of starting their API work in Postman.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "Activate test types before integrating CI. The initial goal is demonstrating breadth of testing methods, not achieving immediate CI integration. Most teams use Postman primarily for individual endpoint checks. Expanding to functional tests, integration tests, smoke tests, and end-to-end workflows - even running locally without CI - shifts the perception of Postman from \"HTTP client\" to \"testing platform.\" Once multiple test types are active and validated locally, CI integration becomes a natural extension of an established workflow rather than a disruptive change. Moving directly from basic endpoint testing to full CI integration with reporting introduces too many changes simultaneously and risks failure.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "Applying the same approach to all three would result in unnecessary work for some customers, insufficient scoping for others, wrong stakeholder engagement, and misaligned success metrics. These customers just bought Enterprise to consolidate individual accounts and small team workspaces. No authoritative workspace topology exists. No consistent naming. No governed access model. No systematic docs or testing.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "Why this is easier: There are no remediation costs or organizational politics around changing existing structures. This accelerates time-to-value and allows us to establish the canonical Domain API Workspace pattern without legacy constraints.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "Onboarding: IT-ready environment consolidation, initial workspace setup matching collaboration patterns. Workflows: Custom implementations for Design/Prototype/Iterate, Build/Test/Deploy, or Promote/Manage Change patterns. Large-scale migrations (>10 domains in parallel). Complete governance framework implementation. Customers unable to execute technical work (require full-service delivery).", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "This session happens at Week 0, before any Path A work begins. It's a 30-60 minute working call with a technical stakeholder who regularly works with the domain's APIs. \"We're going to do something a bit different on tomorrow's call. Instead of us showing you Postman features, we'd like you to walk us through how you currently find and use APIs in [domain name].", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "So instead of you having to go to GitHub, Confluence pages, maybe even Slack somebody to figure out how to utilize a service and integrate it correctly - all that information is just accessible in Postman. It doesn't have to be the full, comprehensive documentation for the API, but we want people to be able to find these APIs, services, and endpoints, the schemas for the responses and requests, and get up and running in 30 seconds.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "We'll time this to establish a baseline. After we onboard this service into Postman, we'll compare the results. Ideally, we compress what might take 30-45 minutes today down to a few minutes. Fragmentation signals: \"Let me check the AWS console... now I need to look at our internal wiki... let me Slack our platform team.\" Tribal knowledge: \"I think [colleague] knows where this is documented.\" \"If I remember correctly...\" Authentication friction: \"I need to generate a token... wait, where do I do that again?\" Documentation gaps: \"The docs are out of date.\" \"This isn't documented anywhere.\" Duplicate effort: \"I built something similar last month, but I can't find it now.\"", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "The exercise ends when: (1) They successfully demonstrate all CRUD operations, (2) They hit a hard blocker they can't resolve, or (3) They reach 30 minutes of effort. Any of these outcomes provides the baseline you need. \"Thank you - that was perfect. It looks like it took us about [X minutes]. I know that felt [awkward/frustrating/tedious], and that's the point. What you just showed us is the baseline we're going to improve.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "The \"before\" state you document here becomes the anchor for every subsequent metric improvement you show in the build log. With this baseline, your Phase 2 results become real, tangible, and direct value delivery metrics. Postman Insights is a lightweight way to get automatic, per-endpoint error and latency visibility across services with minimal setup. Insights accelerates Path A by surfacing where to focus (endpoints with the highest error rates and latency), making failures reproducible (Repro Mode populates Request Builder from real user traffic), and providing alerting that meets teams where they already work (Slack). Reference: Insights overview.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "For endpoints saved from Insights, add collection-level purpose/owner/auth, request-level parameter docs, and 3–5 examples (happy path, auth failure, validation error). Link to canonical docs and repos; publish stable APIs to the Private API Network if applicable.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "Use Repro Mode to load real failing calls into Request Builder; save to collections and add assertions (functional, auth/error, chaining, performance smoke). Target 5–10 critical endpoints plus one E2E workflow. Use Insights trend charts (Errors, Latency) plus Path A adoption/automation metrics to complete the Readiness Scorecard. Present before/after evidence: discoverability time, error-rate reduction, latency improvement, and E2E reliability.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "Week 0 (Reverse Demo baseline): Time current discovery + CRUD flow; capture friction and screenshots for the build log (see Appendix D). Week 1 (Phase 1): Deploy Agent, confirm endpoint inference; save top endpoints to collections; assign maintainers; configure environments; publish first stable collection. Week 2 (Phase 2–3): Add owner/auth docs and examples; enable Repro Mode; convert failing calls into assertions across test types; wire one E2E workflow. Week 3 (Phase 4): Enable Alerts → Slack; make results visible in PR/MR or Slack via CI/Monitors. Week 4 (Phase 5): Compile Insights screenshots and Path A metrics; run the Readiness Scorecard; secure Domain 2.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "Initech stands out as a counter-example; the story didn't resonate because we brought the wrong narrative to the room. The team we're engaged with sees the API catalog as largely solved and is focused almost purely on MCP, and we didn't have the right decision-makers fully engaged; the demo didn't hit the differentiators that mattered for where they are. Strong capabilities do not rescue a misaligned audience. If we don't know the initiative, the stakeholder, and the actual gap, even the most impressive narrative can fall flat.", "label": "positive", "surface": "longform", "topic": "on", "source": "cse-v12-dispatch", "generator": "human", "mimicry": false}
{"text": "The question pattern I want us to keep leaning into is: \"What are the questions you wish you could ask about your API stack right now?\" That gets a leadership team out of shopping mode and into actual platform problems: gateway sprawl, Git-based workflows, Lambda services, ownership, test coverage, deployment confidence. From there the work gets concrete: sandbox, gateway sync, Git integration, pilot scope, then focused enablement.", "label": "positive", "surface": "longform", "topic": "on", "source": "cse-v12-dispatch", "generator": "human", "mimicry": false}
{"text": "Think about Post-sale Engineering as an API for a customer's success: Sales provides the proper inputs in their request, CSE executes, and the response is a success story, an implementation kit, and adoption metrics. In the same frame: garbage in, garbage out.", "label": "positive", "surface": "longform", "topic": "on", "source": "cse-v12-dispatch", "generator": "human", "mimicry": false}
{"text": "The co-execution model produces 4.1x higher success rates (McKinsey) and is critical for a product like Postman, where the entire value proposition changes between single-user and Enterprise. CSE bridges the gap between what customers think the product does and what it can actually do for their engineering organization at scale.", "label": "positive", "surface": "longform", "topic": "on", "source": "cse-charter", "generator": "human", "mimicry": false}
{"text": "AEs own the commercial relationship and post-sale accountability. SEs own pre-sale technical work and can assist with technical activities that don't require a full CSE engagement. But neither function can dedicate the sustained technical co-execution time that enterprise adoption requires. Credibility matters too: customer engineers engage differently with a fellow engineer who's building alongside them vs someone who's presenting slides.", "label": "positive", "surface": "longform", "topic": "on", "source": "cse-charter", "generator": "human", "mimicry": false}
{"text": "Automate. Install CI/CD pipelines that run contract and smoke tests on every deploy. Set up monitors for continuous drift detection. Wire governance rules so spec quality is enforced before merge. Prove. Show measurable results: discovery time reduced from hours to seconds, test coverage from 0% to automated baselines, API health visible in one place for the first time. Quantify ROI for the executive audience.", "label": "positive", "surface": "longform", "topic": "on", "source": "cse-charter", "generator": "human", "mimicry": false}
{"text": "Hand off. Transfer the pattern to the customer's platform/ops team. Leave behind documented workflows, parameterized templates, and a self-serve path for onboarding new services. CSE exits; PS or TAM picks up if the customer wants ongoing support.", "label": "positive", "surface": "longform", "topic": "on", "source": "cse-charter", "generator": "human", "mimicry": false}
{"text": "As Postman becomes embedded in provisioning workflows, CI/CD automation, and governance enforcement, it directly supports release quality, standardization, and operational continuity. CSEs prove the value and create demand. Scaled delivery becomes a revenue stream and ensures adoption continues without expanding CSE coverage indefinitely.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-north-star", "generator": "human", "mimicry": false}
{"text": "Once the adoption model is proven and execution becomes primarily replication at scale, rollout typically transitions to Professional Services, partners, or the customer’s internal teams. CSEs then redeploy to the next high-impact opportunity.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-north-star", "generator": "human", "mimicry": false}
{"text": "Our focus in this phase is replication, not reinvention. We take the automation created in Phase 1 and apply it uniformly across all eligible repositories. Agent Mode Exploration: Show key stakeholders how they can now interact with their deployed services, orchestration, codebases, and their entire end-to-end stack using natural language through a single unified interface – and why it’s powerful if coverage is wall-to-wall and automated. This is how we lead PLG curiosity into enterprise system rollouts.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-platform-playbook", "generator": "human", "mimicry": false}
{"text": "CSE will deliver the pitch and handle the technical activation. Sales owns the door-opening motion: identify the right signal, ask for the right stakeholder, and position CSE as the team that can help the customer turn Postman from useful developer tooling into essential API infrastructure.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-gtm-guidance", "generator": "human", "mimicry": false}
{"text": "Our Customer Success Engineering team works directly with your platform and engineering leaders to embed Postman into the systems that design, test, and ship your APIs. Instead of relying on individual developers to change their behaviour, CSEs partner with you to implement automation that makes best practice adoption seamless. The result is consistent API quality, faster onboarding, and less drift across teams.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-gtm-guidance", "generator": "human", "mimicry": false}
{"text": "What we’re seeing across the industry right now is a growing need to standardize how APIs are built, tested, and governed. Inconsistency drives duplicate work, drift, and poor visibility; this becomes a board-level problem as organizations scale AI.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-gtm-guidance", "generator": "human", "mimicry": false}
{"text": "At the start of Q1, we shared our strategic hypothesis: instead of focusing on changing individual user behavior, we need to focus on building systems that make best-practice adoption automatic. This insight led to the creation of the core CSE playbook: Platform Activation via Spec-Driven Automation.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-q1-fy27-retro", "generator": "human", "mimicry": false}
{"text": "The goal for the next 60 days is simple: turn named account coverage into completed use case activation and reusable proof. Coverage only matters if it creates forward motion. By the end of the quarter, every CSE should be able to point to the accounts they prioritized, the use cases they activated, the value they documented, and the story they produced. Q1 proved that CSE can move from strategy to operating system. We defined the motion, built the playbooks, made the work visible, and delivered early proof through customers like GoodLeap and 7-Eleven.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-q2-kpis", "generator": "human", "mimicry": false}
{"text": "The story includes Before State, After State, Technical Solution + Visuals, and Value Realized. It can be anonymized if we do not have approval for external use, but it must be clear enough for Sales to use with new customers. A build log without a narrative, a customer anecdote without a technical solution, or a usage report that does not explain what changed and why it matters. Sort every named account into P1, P2, or P3 based on readiness for use case activation.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-q2-kpis", "generator": "human", "mimicry": false}
{"text": "The account may be blocked, stalled, not ready, or only engaged through tactical stakeholders with no realistic path to engineering leadership. Document why the account is P3, what would need to change, and monitor. Do not spend heavy CSE cycles here unless conditions or direction change. Once accounts are prioritized, document how you expect to exceed your Q2 KPIs. Review your P1 accounts and form a hypothesis on the specific use case you believe should be activated in each target account.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-q2-kpis", "generator": "human", "mimicry": false}
{"text": "Document your path to 3+ completed use case activation engagements. Please note: engagements assigned via #cse-requests (outside of Named accounts) will count toward your KPIs as well. Identify at least one use case activation engagement that should become a reusable customer success story. Exit criteria: you can clearly explain how you expect to hit 3+ activations and 1+ success story in Q2, and every target account has a named next action.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-q2-kpis", "generator": "human", "mimicry": false}
{"text": "Exit criteria: you can explain the technical opportunity in plain language, why the customer should care, and what must be validated with the customer. Once you have prioritized your accounts and partnered with the AE on account strategy, the expectation is simple: get in front of customers and create forward momentum. This is the proactive part of the motion. Do not wait for perfect conditions. If the account is P1, move quickly into customer execution. If the account is P2, work with the AE, SE, or EM to create the conversation that moves the account closer to activation. The work should be customer-facing, specific, and designed to advance the account.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-q2-kpis", "generator": "human", "mimicry": false}
{"text": "Focus on the work that produces proof. The goal is not activity. The goal is activated use cases and documented value. Do not confuse access with activation. If we only have procurement or tactical admin access, the account is not ready for heavy CSE investment. Partner with Sales on stakeholder access. Sales owns the commercial strategy and relationship path. CSE contributes the technical point of view and supports conversations where credibility matters.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-q2-kpis", "generator": "human", "mimicry": false}
{"text": "Use Health Checks to create pipeline, not as a substitute for activation. A Health Check should produce current state, gaps, recommended activation path, and next step. Document as you go. The build log, proof points, visuals, and customer validation should be captured during the engagement, not reconstructed after the fact. Escalate constraints early. If the blocker is stakeholder access, product gap, support issue, missing data, or customer capacity, make it visible quickly.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-q2-kpis", "generator": "human", "mimicry": false}
{"text": "There is a real executive sponsor, or a credible path to one, with enough organizational authority to keep the initiative moving, unblock decisions, and review value delivered. This sponsor should care about the business outcome the use case supports and be able to help maintain momentum when priorities compete. A pilot without sponsorship becomes a side project. CSE can activate the use case technically, but cannot create organizational will.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-factory-operations", "generator": "human", "mimicry": false}
{"text": "CSE can shape and guide the implementation path, but cannot work in a vacuum. The right technical counterparts are required to execute the work, validate the pattern, and carry it forward after the pilot. The customer is ready to execute, not just explore. Resources are committed to doing the work, customer-side owners have capacity, and there is enough urgency, timeline pressure, or strategic importance to support active execution.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-factory-operations", "generator": "human", "mimicry": false}
{"text": "Are customer resources committed and ready to execute? A request for use case activation is qualified and converted into a processable CSE order. Review the request submitted by the SE. Confirm the exact advanced use case we are trying to activate. Confirm this is not general technical support, feature education, or execution-heavy rollout. Confirm there is an executive sponsor, a technical owner, and customer resources available to do the work.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-factory-operations", "generator": "human", "mimicry": false}
{"text": "Confirm the customer is ready to move beyond exploration and actually implement something. The use case can be described clearly and will activate an advanced use case (list below). The SE has endorsed the request. An executive sponsor or credible sponsor path exists. A customer-side technical owner exists. Customer resources appear committed. The use case is translated into a clear view of the customer’s current state, desired future state, and the simplest path to proving value.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-factory-operations", "generator": "human", "mimicry": false}
{"text": "The concept has been proven internally or in a controlled setup. Core scripts, templates, and assets are prepared. Reusable artifacts are captured in a form other CSEs can use again. The customer takes the proven pattern and implements it in their own environment with CSE guidance. Help the customer apply the prepared pattern in their production-like or production environment. Support setup, integration, configuration, and troubleshooting. Guide the customer technical team through the steps needed to replicate the success in their own systems.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-factory-operations", "generator": "human", "mimicry": false}
{"text": "The implemented use case is confirmed to work as expected and deliver the intended value. Verify that the workflow runs successfully in the customer’s environment. Measure the agreed success signals. Compare results to the original goal. Confirm the use case works reliably, not just once. Capture customer feedback, technical findings, and any changes needed to make the pattern stronger. The use case works in the customer’s environment as expected.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-factory-operations", "generator": "human", "mimicry": false}
{"text": "Agreed success signals have moved or been achieved. The customer acknowledges that value was delivered. The pattern has been shown to work reliably enough to scale or hand off. The successful use case is turned into a case study and repeatable implementation kit that others can use to scale. Finalize the implementation kit based on what worked in the customer environment. Document architecture choices, setup steps, templates, scripts, guardrails, rollout guidance, and known failure points.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-factory-operations", "generator": "human", "mimicry": false}
{"text": "The customer has successfully implemented the targeted advanced use case in their own environment, and it is working in a real engineering workflow. The agreed success signals have moved, and the customer confirms the use case is delivering value. Activating advanced use cases moves Postman beyond the “activity-plane” and proves we deliver value to engineering leadership as well. This will make our platform sticky and increase likelihood of expansion.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-factory-operations", "generator": "human", "mimicry": false}
{"text": "The account team has a clear story showing what changed, how the use case was implemented, what value it delivered, and why it matters. This may be customer-facing or internal-only depending on the situation. Sales can use this to support renewals, justify expansion, create urgency with technical buyers, and show other customers that Postman can drive real workflow change.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-factory-operations", "generator": "human", "mimicry": false}
{"text": "As an AI assistant, I am unable to complete this request without additional context.", "label": "negative", "surface": "jira_standalone", "topic": "on", "source": "seed", "generator": "ai_seed", "mimicry": false}
{"text": "This ticket is currently pending customer action and will remain in Technical Discovery until further notice.", "label": "negative", "surface": "jira_standalone", "topic": "on", "source": "seed", "generator": "ai_seed", "mimicry": false}
{"text": "Worth keeping in view as the broader estate continues to mature and the first slice lands.", "label": "negative", "surface": "jira_standalone", "topic": "on", "source": "seed", "generator": "ai_seed", "mimicry": false}
{"text": "Current status: Technical Discovery. Blocker: awaiting customer response. Owner: AE team.", "label": "negative", "surface": "jira_standalone", "topic": "on", "source": "seed", "generator": "ai_seed", "mimicry": false}
{"text": "**Next steps:** confirm the workshop date, populate the Executive Sponsor field, draft the kickoff agenda.", "label": "negative", "surface": "jira_standalone", "topic": "on", "source": "seed", "generator": "ai_seed", "mimicry": false}
{"text": "The SOW redline is currently under review by legal; we can expect turnaround in 3-5 business days.", "label": "negative", "surface": "jira_standalone", "topic": "on", "source": "seed", "generator": "ai_seed", "mimicry": false}
{"text": "On 2026-05-09T14:22:00Z, I set the Technical Counterpart field to the value provided in the thread.", "label": "negative", "surface": "jira_standalone", "topic": "on", "source": "seed", "generator": "ai_seed", "mimicry": false}
{"text": "My analysis suggests that the customer is likely to be receptive to a follow-on conversation regarding the v12 enablement opportunity.", "label": "negative", "surface": "jira_standalone", "topic": "on", "source": "seed", "generator": "ai_seed", "mimicry": false}
{"text": "Filled Exec Sponsor with the director from the customer side based on the meeting context.", "label": "negative", "surface": "jira_standalone", "topic": "on", "source": "seed", "generator": "ai_seed", "mimicry": false}