{"text": "The agent moved a solid chunk of them to the real stages about an hour ago", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "CSEs are attributed through the Jira board as it's per-project", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "Even better, great minds think alike", "label": "positive", "surface": "thread_reply", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "We can add stuff as a task, sure", "label": "positive", "surface": "thread_reply", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "salesforce stuff will require new custom fields, unless we plan on piggybacking off something existing", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "Haven't had time to look into the \"transcribe with no bot attendee/attendee-facing notification\" thing, but generally I have not been impressed", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "Their agent builder is a worse version of what we've already built", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "waiting on the room", "label": "positive", "surface": "thread_reply", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "and remove the link requirement", "label": "positive", "surface": "thread_reply", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "added cool animations at least", "label": "positive", "surface": "thread_reply", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "A true jared-style presentation", "label": "positive", "surface": "thread_reply", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "Yep it's just one slide lol", "label": "positive", "surface": "thread_reply", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "Or need to split out the bidirectional sync into a ticket and move that one to customer validation, thsi one looks more like it's catalog-focused so it makes sense to keep at this stage", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "can you update the NFL ticket as well? Know we're waiting on Guillermo's signoff but this should be in customer validation", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "This is fucking awesome news btw", "label": "positive", "surface": "thread_reply", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "Which team are you running into this on?", "label": "positive", "surface": "thread_reply", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "do you mind if some of the team sits in on the 7-11 call today? Personally can't join but I think it'll be a good learning experience for those who can, even if just observing", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "Need to explore further", "label": "positive", "surface": "thread_reply", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "Hey! Daniel pinged me and let me know you reached out about Amfam; we have a running log of all customer projects here", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "you should be able to spin stuff up and down in there via se.pm-catalog.dev on command, so just go for it; spin up services and workspaces at will", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "I can share the slides, but we need to figure out how to package it up before we share it with them directly", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "Good question, let me figure it out. It's a launchdarkly flag, i just need to figure out which one", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "Oof I was supposed to fly back to Atlanta on Saturday but have to move my flight forward to tomorrow morning :disappointed: fml\nSwear to god I'm not trying to swerve the birthday party lol, scrambling to re-coordinate with the person renting my house in ATL", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "Elizabeth has mostly stepped back to stop pestering Sam on it, so she doesn't have much more information than we do. I'll start a thread with him", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "Preetham has been engaged in the ongoing thread in #customer-tmobile and should be aware of the background here already, we just need to be very clear in what we communicate on the call tomorrow and ensure we have all the necessary information. If we're ambiguous in any of this, we expect to be challenged", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "Yeah I see that thread from yash; wonder if the cs-demo instance has the beta feature flag enabled?", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "Hey @andor.fuhrer @benjamin.wanless chatting with Lexi and she has a couple account plans / resources for a number of accounts that we want to convert to success plans in gainsight. Opening this thread so we can get the ball rolling on that before we start iterating in gainsight", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "He has a habit of reading the most recent comment and missing the rest of the thread and the OP", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "Hey all, can anyone drop the heatmap spec (or similar) in so we can wire it up with a sandbox? Don't think Javier is in this channel -- if we need to add anyone else here feel free to pull them in", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "We had some ongoing threads with Ankit that I doubt Abhinav has the time to pick up. But we'll see", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "Totally agree, just made do with what was available at the time. That said the ML model training and scoring does need a raw source. Also totally didn't notice kepler-redshift-data-needs.md made it into the zip, the confluence page is the same thing + a human pass to pull out the Claude garbage", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "Weird, it's enrolled in MDM. Just saw this or would have popped by while I was at the office today", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "Hey! I actually totally out of the loop on this -- missed both meetings. Can you ping Allyson?", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "Was leaning towards Hannah as she has a super comprehensive understanding of all the running threads in Jira, even with customers that she doesn't oversee", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "I can move the role over to eu-west-2, haven't done it yet", "label": "positive", "surface": "thread_reply", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "Thoughts on the 7-11 'we dont have a spec for this lambda' problem. Spin up a few lambdas on an empty region -- resolve the specs from aws gateway in CI via list; can use aws cli or official aws actions. Figure out a way to determine what service the repo maps to (doing it manual for 100+ services is nuts). Determine if there's some sort of internal API that does this behind bifrost already; not sure if the AWS gateway integration creates the spec from the gateway and saves to workspace/linked repo or not; need to explore", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "Yeah a CS tool would help, but the cool thing about doing it in Gong is trackers; we can see if Postcon has been mentioned, for instance", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "It has related word forms and even picks up on things that aren't postcon, so if they mentioned it then it would definitely be there", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "Yeah that helps. Markus mentioned some rumors/screen shares of a postman-like tool that allowed running requests, etc but was hosted in Azure -- curious if this has come up anywhere else?", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "@here Hey all, spinning up this channel in an effort to unify the 'customer has a question about X' streams. Domain Capture, Team Copy, and in-app notification requests will remain in the CUSTENGG jira board, but all general requests should be routed here.", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "Sharing this with you all as this went over really well with Fox. We'll chat on it next week", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "@here anybody free to hop on a call with McAfee in a few minutes? @mayur.tare is leading and I'd planned to listen in shotgun with him but had something pop up. No expectations for delivering anything, but if anyone's free it'd be good to listen in", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "Eric's totally swamped, but this may help. Pinged him about our convo yesterday and he directed me here. Targeting much faster than 90 days, but the 90-day opt-out circuit breaker is still a good idea", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "@here hey all, blocking off most of the day Monday to chat with anyone who's interested in moving over to CSE; don't want to leave things hanging out there in limbo. Just grab a slot any time from 9-12PT or 1-5PT", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "Hey @chris.murphy @jaimie.sanita, saw Pfizer coming through and wanted to ask: Do we have an internal slack channel for them? Not seeing anything with a quick search. Who's the field CTO we have slotted to meet with them?", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "Hey all, spinning this up to keep the pfizer chats all in one place. @harry.mower, I threw a few minutes on your calendar Monday to chat ahead of the call with Pfizer next week since it's been a while since we've had a 1:1. In the meantime, have a great Friday/weekend!", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "I honestly agree that a one-way sync with a golden true source of truth is preferable, buuuuut plenty of customers ask for it", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "Let me take a little bit of a look; can you send over the gong link and drop it in the #help-cse channel so the team can game plan around it?", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "Awesome, thanks Chris. We should set up an internal channel just to keep the postman-side chats about them in one place, I'll spin one up", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "@hammad.iqbal can you spin up a gitlab community instance in AWS? we can move the discussion to the #customer-int-7-11 channel", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "Since Will von Kaenel's gone, need a new AE on Chick-fil-a; CSE has a call with them this afternoon at 1PT. Might be a good place to tap @sean.reed in unless you had someone else in mind?", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "@hammad.iqbal, pulling you in on 7-11; there's some history here that I'll catch you up on. @adrian.nardella / @brendan.mcmanus let's grab some time for all of us to chat on this and the plan forward, today if possible", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "Happy to sync up and chat on this @lucas.lage; maybe late afternoon today or tomorrow?", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "Security was looking for some sort of official channel to migrate it over to but haven't heard anything back", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "Also, update on GCP/Azure -- working with @ugo.emeka and @karn.sharma, should have something done here within the next 24 hours", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "I gave you and pavan both admin, you guys should be able to adjust the approval settings + approve and merge @hammad.iqbal", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "Yep, should be fixed now. Still need a minor fix for the 'skip invite emails when person is already an admin'; working on that now", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "Good callout though, should adapt it to not do that when someone already has admin", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "You're already on the team and should be able to see them anyway, so no", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "Perfect, ty. @pavan.nelakuditi you can work with @tamas.rathonyi and whoever he/maren decide to put on this to tune up the agenda if necessary to align with the overall first half teach > second half build approach", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "Do we have that agenda saved somewhere in a doc? Also pulling in @maren.engh", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "Need to chat about a workshop with O'Reilly, just pinging now before I forget", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "He said we could connect on it today, waiting for him to respond with a time slot", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "Hey, let me know when you're free. I can pull in @eric.macdonald as well if need be", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "Hey , what’s the ask from customer engineering on this one? Is this a domain capture/team copy?", "label": "positive", "surface": "jira_standalone", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "The IdP (LDAP in this case) pushes events to Postman, not the other way around, so:\n- Changes in the IdP (removing user from the group) = change pushed to Postman via SCIM API\n- Changes in Postman (removing user from Postman, adding permissions, etc) = Postman has no way to communicate with the IdP to say “hey, update the provisioning group and remove this person”. That would require Postman to authenticate to their IdP and have control over their user groups there, which isn’t a risk we want to take ownership of\nSo to answer their question, yes, they’re correct. If someone is removed manually (in Postman) and re-added manually (via Postman), none of their permissions/etc will come back either –- they need to remove and re-provision via the orchestrator, in this case LDAP.\nIf the goal is to temporarily disable access and restore it later at some point:\n- Unassign the user from the Postman app in the IdP -- this triggers SCIM deprovisioning (sets active: false), and you can reassign later to reactivate.\n- Remove the user from the provisioning scope/group in the IdP -- same effect.\nBoth of these keep the IdP and Postman in sync, so re-provisioning works as expected when you reverse the action.\nTLDR: Once SCIM is set up, they need to do the deactivation/provisioning/permissions management from the IdP side, not from Postman directly.\nDocs:", "label": "positive", "surface": "longform", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "I can take the mapping/discovery call on this, then we can figure out where it goes", "label": "positive", "surface": "jira_standalone", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "just for the first call to map it out. After that we’ll hand it off – I just want to get some sort of a concrete plan down before doing so", "label": "positive", "surface": "jira_standalone", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "should just be flipping the flag, but I do have a session with Charat tomorrow just in case. I should be able to handle it", "label": "positive", "surface": "jira_standalone", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "What's the latest on Lockheed @[andrew]? It's been ~10 days since there was any activity here; if we're blocked for some reason, can we note it in the ticket? Just want to make sure we capture next steps and keep everything observable so we can improve where possible.", "label": "positive", "surface": "jira_standalone", "topic": "on", "source": "examples", "generator": "human", "mimicry": false}
{"text": "Do we have a follow-up scheduled with Foot Locker yet? They seemed like a good candidate, but I've not heard anything about any movement here. There's definitely work we can do here.", "label": "positive", "surface": "jira_standalone", "topic": "on", "source": "examples", "generator": "human", "mimicry": false}
{"text": "Might be worth dropping the link to the workshop plan in this ticket just for posterity @[pavan] -- trying to keep everything in one place", "label": "positive", "surface": "jira_standalone", "topic": "on", "source": "examples", "generator": "human", "mimicry": false}
{"text": "Commenting on this to note that we spoke with Jeremy back on [date], gong link: [link]. Wouldn't expect this to go anywhere in the near future, but we'll keep it on the board to rehydrate if Jeremy comes back and wants to dig in deeper after the renewal.", "label": "positive", "surface": "jira_standalone", "topic": "on", "source": "examples", "generator": "human", "mimicry": false}
{"text": "Totally fine by me, just let me know what we settle on.", "label": "positive", "surface": "thread_reply", "topic": "on", "source": "examples", "generator": "human", "mimicry": false}
{"text": "Agreed, if we can iron out some actual next steps here then we can kick off projects with objectives rather than just building potential solutions. Would love to have mutual agreement on a solid milestone to work towards.", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "examples", "generator": "human", "mimicry": false}
{"text": "Yeah, 100%. Happy to be tag-team this with Pavan", "label": "positive", "surface": "thread_reply", "topic": "on", "source": "examples", "generator": "human", "mimicry": false}
{"text": "[Checks gong and granola transcripts] You said Goodleap had a (maybe less-universal) solution like this that they'd built in house @[hammad]? Curious if you could drop any details here and let me know how that effects this project, if at all. Would be cool if we could \"win\" over the homegrown automation.", "label": "positive", "surface": "jira_standalone", "topic": "on", "source": "examples", "generator": "human", "mimicry": false}
{"text": "[after gong/granola research] Two things to drop here based on our slack converation today and 1 on 1 this week: Manudeep's working on a similar xray integration with Eli Lilly, so we should pick his brain on how this rolls into the product (if he's thought that far) + the design partner thing with Goodleap. Also wonder if there'd be any willingness between Goodleap <> Eli Lilly to chat with each other? Might be worth setting up. Both ideas to ping Manu on.", "label": "positive", "surface": "jira_standalone", "topic": "on", "source": "examples", "generator": "human", "mimicry": false}
{"text": "[agent researches the repo, sees it's unfinished] Typically don't want to just jump a repo on a customer without walking through it, and there are some considerations to be made with this one that we should talk through with them directly. I'll defer to Austin on this one", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "examples", "generator": "human", "mimicry": false}
{"text": "Sorry for the delayed response, got behind on slack. If still necessary we can grab a few minutes to talk it through. Honestly, we can probably reuse a lot of existing material; it's really just a spec-driven development workshop with a spec-driven asset-creation + testing + automation tail that Pavan and I can handle", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "examples", "generator": "human", "mimicry": false}
{"text": "[agent searches gh repos, reads verizon repo and most recent calls with verizon] I have not; it's ready-to-share though, also includes some ideas around how they could make this more accessible to partners: A flag/route on Verizon's existing production gateway, gated by a pre-registered partner client id and/or Test-MDN pool on stationary test SIMs (what we talked about on the call)", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "examples", "generator": "human", "mimicry": false}
{"text": "Hey @[hammad], what's up with these guys? Haven't heard much about this, should we move it to blocked?", "label": "positive", "surface": "jira_standalone", "topic": "on", "source": "examples", "generator": "human", "mimicry": false}
{"text": "[agent does research on the customer] 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": "examples", "generator": "human", "mimicry": false}
{"text": "[agent does research in granola and sees my 1 on 1 transcript with sean] Hey @[sean], just a reminder to reach out to Manudeep on this one if you haven't already to see if we can team up with FDE; they might have other contacts they're working with on the Lilly side.", "label": "positive", "surface": "jira_standalone", "topic": "on", "source": "examples", "generator": "human", "mimicry": false}
{"text": "Hey @[etienne], can you help pull in some of the context on this one? With limited transcript history for EMEA accounts I want to make sure we're capturing as much info as possible here on the board -- once we get a CSE assigned we'll handle it on our end, but the more background you can provide the better. Thanks!", "label": "positive", "surface": "jira_standalone", "topic": "on", "source": "examples", "generator": "human", "mimicry": false}
{"text": "[checks granola history] Don't have majorly high hopes on this one moving through any effort of our own, but it might be worth just a quick ping to Jeremy. This is actually one where a field CTO might do the trick, or Ankit. Worth a shot @[hammad]", "label": "positive", "surface": "longform", "topic": "on", "source": "examples", "generator": "human", "mimicry": false}
{"text": "I wonder if maybe providing him with some tuned-up testimonials from other customers who have built it out might give him ammunition to find that pilot team @[dan]. Thoughts?", "label": "positive", "surface": "jira_standalone", "topic": "on", "source": "examples", "generator": "human", "mimicry": false}
{"text": "Thanks @[jelle]. Deferring to @[eric] here; is this something we leverage support for? EMs? Data stuff is way out of CSE's wheelhouse, but we might be ablet to make some sort of team effort towards a unified approach here and line CSE up for something", "label": "positive", "surface": "jira_standalone", "topic": "on", "source": "examples", "generator": "human", "mimicry": false}
{"text": "[agent checks granola + slack history] Let's chat on this @[hichem]. We have a number of things that we can track for impact post v12, but the traceability comes from integration, not just flipping the switch.\nIt's the things that come *after* flipping the switch that matter -- there's integration work that we can work on with their delivery/devops stakeholders. CSE's happy to walk through the narrative and see if we can get a project lined up.", "label": "positive", "surface": "jira_standalone", "topic": "on", "source": "examples", "generator": "human", "mimicry": false}
{"text": "[agent reviews last call transcript] I think the Apigee migration is done at this point? Chanakya said by end of this week. Not sure if we've connected with him. Any word @[hammad]?", "label": "positive", "surface": "jira_standalone", "topic": "on", "source": "examples", "generator": "human", "mimicry": false}
{"text": "[agent sends a self-slack message to me pointing it out + urgency. no direct message back to arjun]", "label": "positive", "surface": "longform", "topic": "on", "source": "wave", "generator": "human", "mimicry": false}
{"text": "I set Executive Sponsor to Binoj Ammeripadath, Sr. Director Product QA. @jane gut check?", "label": "positive", "surface": "jira_standalone", "topic": "on", "source": "prose-voice", "generator": "human", "mimicry": false}
{"text": "Locking in Technical Counterpart as Brad Trevaskis, Principal Architect -- @mike sound right to you?", "label": "positive", "surface": "jira_standalone", "topic": "on", "source": "prose-voice", "generator": "human", "mimicry": false}
{"text": "@alex who should we use as TC here? Gong has two candidates, Sergei on the April call and Dana on the March call; nothing resolves the tie.", "label": "positive", "surface": "jira_standalone", "topic": "on", "source": "prose-voice", "generator": "human", "mimicry": false}
{"text": "For Problem Statement, every transcript I pulled covers the *how* but nothing states the business outcome. @jane worth a two-line rewrite?", "label": "positive", "surface": "jira_standalone", "topic": "on", "source": "prose-voice", "generator": "human", "mimicry": false}
{"text": "Workshop lands next week and TC is still TBC. @priya who's been closest to the platform work on their side?", "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, and Impact Metrics are narrative right now, no number or timeframe. @jane @mike can you take a pass?", "label": "positive", "surface": "jira_standalone", "topic": "on", "source": "prose-voice", "generator": "human", "mimicry": false}
{"text": "Holding on Technical Counterpart and Problem Statement. No Platform/SRE lead named in Gong since Feb, and the current problem text reads like a scoping note rather than a statement. @alex @priya worth 10 min at the next sync?", "label": "positive", "surface": "jira_standalone", "topic": "on", "source": "prose-voice", "generator": "human", "mimicry": false}
{"text": "Lockheed hasn't moved, but the Gong call makes it sound like Ana already validated the workspace flow. @andrew should we mark this ready for Pilot Validation or is there another blocker I'm missing?", "label": "positive", "surface": "jira_standalone", "topic": "on", "source": "prose-voice", "generator": "human", "mimicry": false}
{"text": "Shake Shack's Gong call had Sarah asking for a CI follow-up, but this hasn't moved in a couple weeks. @pavan do we have that scheduled or should we backlog it?", "label": "positive", "surface": "jira_standalone", "topic": "on", "source": "prose-voice", "generator": "human", "mimicry": false}
{"text": "Datadog's Slack thread has them asking for the repo handoff, but the ticket is still sitting in discovery. @priya should we move this forward or is there a blocker not captured here?", "label": "positive", "surface": "jira_standalone", "topic": "on", "source": "prose-voice", "generator": "human", "mimicry": false}
{"text": "You said GoodLeap had a homegrown solution like this @hammad -- any details you can drop here on how that affects the project, if at all? Would be cool if we could \"win\" over the in-house automation.", "label": "positive", "surface": "jira_standalone", "topic": "on", "source": "prose-voice", "generator": "human", "mimicry": false}
{"text": "Two things to drop here based on our slack convo today: Manudeep's running a similar Xray integration with Eli Lilly, worth picking his brain. Also wonder if there'd be willingness between the two sides to chat directly.", "label": "positive", "surface": "jira_standalone", "topic": "on", "source": "prose-voice", "generator": "human", "mimicry": false}
{"text": "Hey @sean, just a reminder to reach out to Manudeep on this one if you haven't already to see if we can team up with FDE; they might have other contacts they're working with on the Lilly side.", "label": "positive", "surface": "jira_standalone", "topic": "on", "source": "prose-voice", "generator": "human", "mimicry": false}
{"text": "I think the Apigee migration is done at this point? Chanakya said by end of this week. Not sure if we've connected with him. Any word @[hammad]?", "label": "positive", "surface": "jira_standalone", "topic": "on", "source": "prose-voice", "generator": "human", "mimicry": false}
{"text": "Chick-Fil-A still has the 3/30 placeholder and I don't see anything back from Jeremy. @pavan if we're blocked on their side, we can probably move this into backlog.", "label": "positive", "surface": "jira_standalone", "topic": "on", "source": "prose-voice", "generator": "human", "mimicry": false}
{"text": "cause I'm 100% sure we've got plenty of capacity right now", "label": "positive", "surface": "thread_reply", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "or if we're truly blocked and waiting on next steps, we gotta massive increase inventory (activate engagements) in our work system", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "that being said, its more than just ticket hygiene. I can't help but feel we're moving too slow with a bunch of these customers. Unblocking may require looking beyond CSEs", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "Review tickets with the new updates -> review factory operations guideline -> update ticket to where it should be based on context", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "walk me through it monday. i was literally building an agent to do exactly this next lol", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "No transcripts makes sense, but I imagine we would want to push the summaries in", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "As for Jira, the Lorren agent runs nightly and checks recent activity via Kepler and posts an update tailored to the goal outlined in the ticket. Assuming we have api access to Salesforce (or Kepler pulls there already), it will be easy to fold the air cover updates in with that", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "Lets grab 30 min Monday or Tuesday to quickly align on activity flows into jira. Just want to make sure we don't duplicate efforts", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "if it's the same level of effort, could we prioritize Salesforce injection?", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "Board is getting heavy on the left!", "label": "positive", "surface": "thread_reply", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "Next week we gotta figure out how to increase throughout. We have a huge backlog building before customer validation that doesn't seem to be progressing", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "Most customers don't like recordings. We need a silent transcriber (granola, notion, aircover, etc)", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "cause then yeah we can easily point the archivist agent we just launched to synthesize and update tickets", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "and in a system we can easily query", "label": "positive", "surface": "thread_reply", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "for me the biggest thing i care about is ensuring all customer activity is recorded and tracked", "label": "positive", "surface": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "where did we leave off with aircover? would love to get that rolled out to the INTL folks asap", "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": "slack_dm", "topic": "on", "source": "corpus", "generator": "human", "mimicry": false}
{"text": "Customer Success exists to help Postman make money by improving retention and expansion. Retention improves when Postman becomes embedded in the systems that govern and ship APIs, not when it remains optional developer tooling. This will make Postman structurally hard to remove and create the conditions for expansion. As a result, our goal is to maximize the percent of ARR that is embedded. Achieving this requires execution across three reinforcing layers. Stakeholder Alignment: know the customer's business, power structure, technical reality, and desired outcomes. Use Case Activation: help customers adopt high-value use cases and workflows that make Postman operationally important. Awareness of Impact: document and socialize the impact we're making so customers understand why Postman matters and what actions they can take to compound value realized.", "label": "positive", "surface": "longform", "topic": "on", "source": "confluence-charter", "generator": "human", "mimicry": false}
{"text": "Stakeholder alignment gives us access to better problems. Better problems create better use case activation opportunities. Use case activation creates proof. Proof earns us the right to go higher, wider, and deeper. That restarts the cycle with increased momentum. That is the Value Expansion Flywheel.", "label": "positive", "surface": "longform", "topic": "on", "source": "confluence-charter", "generator": "human", "mimicry": false}
{"text": "Being assigned to an account means you are expected to meet a clear standard of coverage. It does not mean you own every customer conversation or job to be done. The AE remains accountable for the overall account strategy, commercial outcome, and establishing relationships with the right stakeholders. For example, if the account is only engaged with procurement or other tactical stakeholders, Sales must lead the work to establish the right relationships, with CS supporting through joint discovery, technical credibility, and targeted outreach where appropriate.", "label": "positive", "surface": "longform", "topic": "on", "source": "confluence-charter", "generator": "human", "mimicry": false}
{"text": "Our goal is to maximize the percentage of ARR that is embedded. Embedded means Postman is not just a tool developers like; it means Postman is woven into their engineering operating rhythm. In the most mature accounts, Postman is integrated, plugged into how engineers already work, not sitting off to the side as a parallel system. It is automated, so specs, collections, tests, docs, monitors, and catalog entries stay in sync without manual effort. It is governed, with standards enforced in systems and pipelines, not through tribal knowledge or after-the-fact review boards. It is discoverable, so APIs are findable, runnable, and trustworthy by engineers, partners, consumers, and agents. When Postman is embedded this way, removing it creates operational pain. That is what we are trying to accomplish.", "label": "positive", "surface": "longform", "topic": "on", "source": "confluence-charter", "generator": "human", "mimicry": false}
{"text": "Following engineering-driven purchases, a traditional customer journey works well. Our 4-stage journey remains a helpful guide for that profile of customer. However, many of the accounts that we'll be working with are existing customers who purchased to secure and administer Postman. When this happens, our buyers are primarily interested in mitigating the risk associated with Postman Free and setting up Enterprise controls like SSO, SCIM, and RBAC. After IT Onboarding, we're placed in a difficult position; we've solved their reason for purchase, but we are not connected to buyers who aspire to do more. This is not durable revenue. Handling these customers requires a more dynamic lifecycle that can be influenced in multiple directions.", "label": "positive", "surface": "longform", "topic": "on", "source": "confluence-charter", "generator": "human", "mimicry": false}
{"text": "This is called the Value Expansion Flywheel; it provides a simple framework for assessing the health of your accounts and understanding the next best action. First, we understand the customer well enough to form a point of view on how Postman can help their business. Second, we use that point of view to align with the right stakeholders. Third, we turn alignment into use case activation. Fourth, we turn activation into evidence. Fifth, we use evidence to earn the right to do more. Then the cycle repeats.", "label": "positive", "surface": "longform", "topic": "on", "source": "confluence-charter", "generator": "human", "mimicry": false}
{"text": "The flywheel is not linear in practice. Use it to diagnose gaps and shape your strategy. If you have weak stakeholder alignment, it may make sense to start by engaging a group of power users, documenting their use cases and associated impact, and then using those proof points to get higher. If you have weak use case activation, work to understand what their key stakeholders care about, and then request their sponsorship to drive change. If an activity does not improve stakeholder alignment, use case activation, or awareness of impact, we should question why we are doing it.", "label": "positive", "surface": "longform", "topic": "on", "source": "confluence-charter", "generator": "human", "mimicry": false}
{"text": "Core motions are the repeatable plays we run to execute the strategy.", "label": "positive", "surface": "longform", "topic": "on", "source": "confluence-charter", "generator": "human", "mimicry": false}
{"text": "Shape Strategy is about forming and maintaining a point of view. The best reps know their customers better than the customers know themselves, and they use that understanding to advise and challenge them. This starts with the Account Plan. An account plan should have a point-of-view on how Postman can impact their business, as well as what we need to do to execute on that vision.", "label": "positive", "surface": "longform", "topic": "on", "source": "confluence-charter", "generator": "human", "mimicry": false}
{"text": "Once assigned to an account, your first job is to understand the current state and help shape the strategy. If an account plan doesn't exist, partner with the AEs to create one. Account planning requires research across news, investor reports, and industry trends, aligning with Sales on commercial objectives and customer priorities, analyzing usage and meeting activity, forming a hypothesis on where Postman can add more value, and defining the next best action. If there are blind spots, collaborate on a plan to close those gaps through customer execution.", "label": "positive", "surface": "longform", "topic": "on", "source": "confluence-charter", "generator": "human", "mimicry": false}
{"text": "Stakeholder Alignment is about engaging the people who own the problems Postman can solve. The goal is not generic relationship management. The goal is to understand what matters, why it matters now, who owns it, what is preventing progress, and how Postman can help. The higher we engage, the more we focus on strategy: which problems matter most, why now, what happens if nothing changes, who owns the outcome, and what success looks like. The closer we get to operators, the more we focus on execution: what workflows are painful, what systems and tools are involved, where work breaks down, what is manual or duplicated or inconsistent or invisible, and who can actually implement change. Our job is to connect the two. When we do this effectively, we teach the customer something new about their business and help them act on it. There is no better way to build trust and credibility.", "label": "positive", "surface": "longform", "topic": "on", "source": "confluence-charter", "generator": "human", "mimicry": false}
{"text": "You are responsible for engaging stakeholders at multiple levels to better understand their goals, identify how Postman can help, and earn the sponsorship required to drive change. If you have a strong Champion, use them to facilitate introductions to other teams internally. If you don't, partner with Sales and Marketing to find creative ways to generate engagement. This might be running Account Based Marketing campaigns to generate new leads, collaborating with partner solutions to set up Lunch n Learns or Hackathons, working with Account Development Reps to facilitate meetings, or crafting and sending your own outreach to relevant customer stakeholders. As we establish credibility and document proof points, it will be easier to get wider and higher.", "label": "positive", "surface": "longform", "topic": "on", "source": "confluence-charter", "generator": "human", "mimicry": false}
{"text": "Bad Stakeholder Alignment means we only work with procurement, IT administration, or a friendly end user. Conversations are about licensing, usage reports, support issues, or generic enablement. Good Stakeholder Alignment means we are multi-threaded across admins, operators, managers, and at least one director-level stakeholder. We understand a real engineering problem and have identified who owns it. Great Stakeholder Alignment means we are working with a VP of Platform Engineering, DevEx, DevOps, Governance, or equivalent leader on a strategic initiative. We also have direct access to the technical operators who can implement change.", "label": "positive", "surface": "longform", "topic": "on", "source": "confluence-charter", "generator": "human", "mimicry": false}
{"text": "Stakeholder alignment tells us what matters. Use case activation proves we can do something about it. This is the most important pillar. Without meaningful product adoption, we only have aspiration. Our job is to help customers discover and adopt use cases that improve workflows and drive their desired outcomes. The more use cases we activate, the greater our ability to document measurable outcomes and build compelling proof points.", "label": "positive", "surface": "longform", "topic": "on", "source": "confluence-charter", "generator": "human", "mimicry": false}
{"text": "Everyone should be capturing value continuously through day-to-day customer engagement. This includes customer quotes, anecdotes, pain points, goals, use cases, blockers, adoption signals, and examples of where Postman is becoming more important to the customer's business. Value capture is especially important during use case activation work. At minimum, we should capture what problem we solved, what changed, what value was created, and what opportunity remains. Case studies and build logs are a key source of this, but they should not be the only source.", "label": "positive", "surface": "longform", "topic": "on", "source": "confluence-charter", "generator": "human", "mimicry": false}
{"text": "Bad Awareness of Impact means we can only point to user activity, but not business impact. Good Awareness of Impact means we have documented the problem, the change, the outcome, and the next opportunity. The customer confirms the value. Great Awareness of Impact means we have an executive-facing value story that connects Postman to a strategic customer priority. The customer promotes the story internally and the account team uses it commercially.", "label": "positive", "surface": "longform", "topic": "on", "source": "confluence-charter", "generator": "human", "mimicry": false}
{"text": "Customers are asking for new capabilities to close product gaps, and we're working on those. But they're also asking for something equally critical: how to use what they already have effectively, and how to prove it's worth the investment. We've developed comprehensive internal guidance on how Postman should be used to solve real platform engineering problems: API discovery and cataloging, collaboration patterns, test automation, governance workflows, observability integration, change management, and auditable trails. These patterns are documented in our \"How to Use Postman\" guides (Internal API Collaboration, Test Automation, Governance, Partner and Public API Collaboration, Workflow Documentation, Toolchain Integration).", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "Even if we see high collaboration metrics in Looker, the reality on the ground may be workspace sprawl, missing documentation, and duplicate collections everywhere. Engineers continue jumping between systems because Postman doesn't contain what they need, which reinforces the habit of looking elsewhere first and prevents us from becoming the first place users go for API development. The 2025 State of the API Report confirms this pattern: 93% of developers face collaboration blockers, 55% struggle with inconsistent documentation, and 34% can't discover APIs that already exist within their own organizations. The people surveyed for the State of the API Report are our own customers.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "This creates the renewal risk. Without engineering value that's measurable and embedded in workflows, there's nothing preventing teams from dropping back to free tiers or trying alternatives. And without proof that the approach works, we can't expand into additional domains or buying centers.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "This is the field execution version of the \"How to Use Postman\" guides. Each phase maps directly to a guide and informs the way we build an integrated journey. Day 1: We start two parallel tracks. The CSM works with IT on org foundation work (SSO, provisioning, user governance policies - targeting completion by Month 3). Simultaneously, a CSE embeds directly with a pilot domain's engineering team to implement the first Domain API Workspace in 2-4 weeks. Weeks 5-8: We use Domain 1 as proof to secure Domain 2. The patterns are established, the build log shows measurable outcomes, and customer tech leads from Domain 1 can advise Domain 2. Weeks 9-16: Repeat the template for domains 3 and 4. By this point, customers are executing with minimal CSE involvement. End state after 3-6 months: Engineering value is documented, measurable, and embedded in daily workflows. Postman becomes infrastructure that engineering teams depend on and executive sponsors champion.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "We document the transformation: build logs with before and after screenshots, measurable improvements in onboarding time and discoverability, customer quotes from engineers who experienced the change. Active users trending up, test cases expanding, test pass rates improving, time-to-first-call improvements. The beginning state and end state of all of these is snapshotted so that we can show progress.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "This documentation serves two audiences: CSMs use it to justify expanding to additional domains, and customer executive sponsors use it to defend renewal decisions. The CSM’s role is to broker buying center relationships, identify domains, and coordinate sessions. CSEs work directly with customer engineers in co-working sessions - same room (virtual), building workspaces together, activating aspirational test cases together, wiring CI together. This is pair programming. The CSE guides in real time.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "Track 1: Org Foundation CSM coordinates with IT. SSO, provisioning, baseline governance, users in the platform. The target is to have users functional by Month 3. Throughout this, the CSM continues business discovery and owns keeping everything aligned with business objectives.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "Week 0 - Work with a technical stakeholder. Live on a call, have them pick a service and walk through what they would have to do to figure out how to properly craft a CRUD workflow for that API. Time them from start to completion. Document every step they take (console navigation, wiki search, whatever).", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "This metric justifies workspace creation before we touch testing or CI. It maps to the API Platform definition in RFC-139 (search and discovery as core abstractions). Executives understand it immediately when you show them the before/after, and the gains here are exponential.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "Traditional onboarding fails because it skips ingestion. Teams jump straight to \"cool features\" and wonder why adoption stalls. The reason is simple: if engineers don’t know that Postman has the information they need, they won't live in it.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "Path A inverts this. We ingest 80%+ of a domain's APIs definitions first. We layer on more verbose documentation, more advanced collaborative patterns, and automation later. Without complete ingestion, everything else will fail because the developers are going to be going elsewhere for information regardless.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "What we're doing: First, we inventory where API definitions actually live - gateways, cloud portals, repos, wikis. These definitions need to exist in Postman so developers have minimal reason to leave the platform to understand API functionality. We set up environments (Dev/QA/UAT) with proper baseUrl and auth placeholders. We build collections with all endpoint and method definitions. We add enough documentation so engineers understand what each API does. We assign at least 2 maintainers per workspace. We publish one stable collection that serves as a one-stop shop for utilizing the API.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "Why this matters: When API definitions are scattered across multiple systems, engineers face delays finding APIs, rely on institutional knowledge to locate resources, duplicate effort across teams, constantly switch between platforms, and multiply documentation and testing work. The longer APIs remain fragmented, the more these costs accumulate across the organization.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "Consolidating API definitions into Postman without leveraging our strengths in making it actionable and executable only gets us partway there. Phase 2 is where we lean into our strengths and leverage Postman-specific functionality to remove barriers to consuming the APIs.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "The difference between Postman and traditional API docs is executability. Engineers don't just read about an API - they leverage guided auth to accelerate onboarding, they run it inline, and they modify and build with it in the same environment.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "We're not trying to wholly replace comprehensive API reference documentation; it can continue to live in a developer portal if the customer desires. We're answering the four questions engineers ask when they need to use an API: This is where documentation becomes actionable. External portals may remain, but Postman becomes a one-stop shop for engineers to do what they need to do.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "The goal isn't 100% coverage. The goal is demonstrating the breadth of testing possible with Postman and the value of doing it before we ever wire anything into CI. We activate a breadth of test types per the official Test Automation guide: Exploratory, Functional, Smoke, Integration chaining. The point is showing comprehensive value beyond \"hit endpoint, check for 200.\"", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "The first domain with any customer is where we figure out what works for their specific environment - where their API definitions live, how to get them into Postman, what their auth patterns look like. The second domain within that same customer is where we prove the approach is repeatable with less hands-on CSE work. By the third domain, that customer is running most of it themselves with CSE spot-checks.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "How this scales across the portfolio: The CSE does most of the technical execution work (co-working sessions, hands-on guidance), while the CSM handles coordination, buying center relationships, and business case assembly. Once a CSE has validated this approach with one customer's first domain, they understand the pattern well enough to run first domains with other customers in parallel.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "Every customer's first domain requires discovery work - their API landscape, auth patterns, and infrastructure are all unique. But the framework (Phase 1-5, co-working sessions, acceptance criteria) stays consistent. The key is that CSEs are teaching the pattern through co-execution, not doing all the work for the customer.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "After validating the approach with the first domain, each subsequent domain follows a structured 2-4 week cycle with four co-working sessions, clear homework, and defined acceptance criteria. What tends to fail: Skipping comprehensive ingestion to move quickly into testing or CI integration. When API definitions remain fragmented across cloud consoles, wikis, and tribal knowledge, engineers continue jumping between systems to find what they need. This system-hopping establishes Postman as one tool among many rather than the primary entry point for API work. Each successful workflow that starts elsewhere reinforces the habit of looking for APIs outside Postman first. Without comprehensive ingestion, Postman never becomes the default starting point, which prevents adoption from taking hold.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "Documentation makes Postman the easier choice. The flexibility of the collection format creates variability in quality. A canonical collection that clearly describes domain service behavior makes Postman more useful than the alternatives. When engineers can find working auth examples, clear request documentation, and links to deeper resources within Postman, they stop context-switching to other systems. Each piece of documentation reduces friction and reinforces Postman as the primary workflow.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "Track renewal-relevant metrics. Renewal decisions require answering \"What problem did this solve and how much better are we now?\" Metrics like active users, CI run frequency, test pass rates, and cross-domain consumption only become renewal-relevant when they show measurable improvement from a documented baseline. This is why Path A starts the build log at Week 0 with baseline screenshots and measurements. Without the before-state, current metrics are just numbers. With documented improvement, they become evidence that Postman solved real problems. Customer quotes amplify this by showing engineers valued the change. The tracking strategy isn't just measurement - it's building a defensible renewal case from day one.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "Maintain consistency across domains. Each domain follows the same 2-4 week sprint structure. This consistency serves multiple strategic purposes beyond operational efficiency. It makes success replicable - domain leads can look at previous build logs and see the exact path they'll follow. It makes knowledge transferable - tech leads from domain 2 can get specific, actionable advice from domain 1's team because they're executing the same process. It makes outcomes comparable - when every domain follows the same phases, variations in results reveal what's working and what needs adjustment rather than reflecting process differences. Most importantly, consistency allows customers to internalize the pattern and eventually execute independently. Without it, each domain becomes a custom project requiring full CS involvement. With it, each domain reinforces the template and accelerates adoption of the next one.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "Structure for capability transfer. CSMs track progression through dependency phases. CSEs provide intensive initial guidance, then validate as Customer Tech Leads execute with increasing autonomy. This graduated reduction in CSE involvement ensures capability transfers to the customer team, creating lasting ownership rather than dependency on external resources.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "Not every Path A customer starts from the same place. The core principles stay the same - establish Domain API Workspaces, activate test automation - but tactical execution varies depending on whether you're working with a blank slate, a large existing team, or a foundation-repair situation.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "Path A customers share a commonality: IT- or Security-mandated Postman consolidation. There are differences, though. and how they arrived at that point matters. A new Enterprise customer bringing scattered free users under governance faces different challenges than a customer with 1,000 existing users in an existing Postman instance. Both are different from a customer whose initial Enterprise implementation failed and now faces renewal risk.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "Signals you're in this scenario: There is no authoritative workspace topology. API collections are sparse or incomplete. Lifecycle tags, environments, and PR/fork workflows are not established. Documentation exists outside of Postman. CI integration and automated testing are absent.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "These customers have existing workspace structures, collection libraries, and established usage patterns. The critical unknown is quality. They may have organically developed sound practices that need governance layered on top. They may have high collaboration numbers, but the quality and value of that collaboration may be limited.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "The only way that we'll know is to look. High user counts and collaboration metrics can mask serious structural problems: workspace sprawl with hundreds of unorganized collections, widespread duplication, hardcoded values instead of proper environment management, missing lifecycle tags, and tribal knowledge dependencies.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "This scenario requires careful political navigation. Teams have established workflows, and resistance to structural changes can exceed the technical complexity of migration itself. When to use this approach: This applies when a customer is upgrading from Free or Professional tier with hundreds to thousands of existing users. The quality and structure of their current usage is unclear, and multiple workspaces and collections exist with inconsistent standards across them.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "Why assessment first matters: A structured assessment and remediation plan reduces the risk of disruption during migration. Quality improvements such as deduplication, proper tagging, and environment configuration enable more credible collaboration metrics.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "Signals you're in this scenario: The customer has high user counts, but the quality of their usage is unclear. Collaboration metrics appear strong on paper, but structural issues are suspected. Teams have established workflows that may create resistance to change.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "Target customers for this scenario have been on Enterprise for 6 or more months with low adoption and are now facing renewal risk, whether they admit to it or not. These accounts face renewal risk because the initial implementation failed. Whether self-executed or poorly guided, they never established the hub, automation, and other foundations that justify the Enterprise investment.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "Engagement remains low despite licenses being available. The account shows minimal active users, few or no Published collections, limited test method utilization, and limited or no integration with automation. Teams are still relying on tribal knowledge or external documentation.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "This scenario requires both urgency and scope discipline. Comprehensive remediation is not feasible in the available timeframe. The Rescue Sprint approach focuses on proving value with one domain and one end-to-end workflow within 2-3 weeks, securing renewal commitment, then backfilling the broader foundation.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "When to use this approach: The customer has been on Enterprise for 6 or more months with low adoption and renewal risk. The initial implementation did not establish the foundations needed to justify the investment. Why the rescue-first approach works: A fast, evidence-backed win changes value perception and creates breathing room. Focusing scope prevents getting mired in comprehensive remediation when time is limited. The broader foundation work can happen after the renewal is secured, but we can't just sit around and pray either.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "Signals you're in this scenario: Renewal conversations have already started or are imminent. Someone on the customer side is asking \"what are we getting for this investment?\" The executive sponsor needs concrete proof of value to defend the renewal, and they need it in weeks, not months. There's organizational memory of a previous attempt that didn't deliver, creating skepticism that needs to be overcome quickly.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "CSEs handle standard domain sprints: guiding ingestion from common sources, demonstrating test patterns, and providing CI templates. When complexity exceeds this scope, we escalate to Professional Services or Forward Deployed Engineering. The trigger isn't \"this is hard\"; it's \"CSE hands-on-keyboard time will exceed 20 hours\" or \"the customer can't execute even with active guidance.\"", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "Professional Services (PS) Escalation: Escalate to Professional Services (PS) when a customer requires a fully managed 'Onboarding' engagement to get set up securely for scale, or a custom 'Workflow' engagement to solve a specific business problem not covered by standard CSE guidance.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "Forward-Deployed Engineering (FDE) Escalation: Escalate to Forward-Deployed Engineering (FDE) when a customer requires a novel, bespoke solution that extends Postman's core capabilities, such as the project to enable 'Postman Monitors in Acme's private environment.' This is for challenges that cannot be solved with existing product features and require deep, embedded engineering work.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "When to engage: Use the Trigger Criteria above as decision points for escalation; if the scope threatens sprint timelines or requires non-standard integrations, we need to engage the proper team immediately. Professional Services (PS): Time-bound engagements that accelerate onboarding outcomes (ingestion at scale, dedupe automation, governance rollout, non-standard CI wiring). PS delivers with clear SOWs and returns maintainable assets to the customer team. Forward-Deployed Engineering (FDE): Embedded engineering for complex, in-environment workflows (custom tooling, platform integrations). FDE converts solutions into reusable templates and guidance for CS/CSE and product. Handoff flow: When a trigger is identified, the CSE and AE assess the scope with either PS or FDE. For PS engagements, they pull in professional services to create a statement of work that defines measurable Path A outcomes. For FDE engagements, FDE embeds directly with the customer to solve the problem. During execution, the CSE shadows the work to learn and transfer capability back to the broader CS team. Once complete, the customer returns to the standard Path A cadence, and we update our templates and Build Log with what was learned.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "This is how we establish the baseline for the Discoverability Time metric. Instead of demoing Postman to the customer, we have them demonstrate their current API discovery and integration workflow to us. This serves three purposes: it quantifies the \"before\" state for our build log, it reveals exactly which systems we need to ingest from in Phase 1, and it creates an organic narrative that executive sponsors understand immediately.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "The goal is to make Postman the place developers can go to get up and running with the APIs they need to use extremely quickly. To do that effectively, we need to understand your current workflow - where you look for documentation, how you figure out auth, all of it.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "We'll pick a service API, and you'll show us what you'd do today to build a working CRUD workflow for that API. Plan for 30-60 minutes, and come ready to screen-share.\" \"Thanks for taking the time. Let me explain what we're trying to accomplish here. The best way we see enterprises use Postman is to have it serve as the place that developers can go to get up and running with the APIs they need to use to build stuff extremely quickly.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "To make that work for your environment, we need to understand your current workflow. When you need to integrate with a service, how do you figure out what it does, how to authenticate to it, what a working request and response look like, and where to go for more detail? We want to see that discovery process step by step.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "Let's think about your current work. Is there anything you're working on right now, or anything on your to-do list, where you need to figure out how to use a service or API that you haven't used before? Something where you'd need to go hunt down documentation, figure out auth, and build a working integration?", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "If nothing current comes to mind, we can pick one of your domain's services that you're somewhat familiar with but haven't touched recently. Either way, we'll walk through how you'd build a basic CRUD workflow for it - Create, Read, Update, Delete operations. Show us everything: where you'd look for documentation, how you'd figure out auth, where you'd test requests, all of it.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "If they say: \"I would normally just ask [colleague]...\" You respond: \"That's valuable information - I'll note it down. But for this exercise, pretend [colleague] isn't available. What would you do?\" If they say: \"If I remember correctly...\" You respond: \"Try to show us the steps as if you were doing it fresh. Walk us through each one.\" If they try to explain instead of showing: You say: \"Actually, rather than explaining, can you share your screen and just do it? It helps if we can see the real workflow, clicks and all.\"", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "If they start showing you their existing Postman setup: Acknowledge it briefly, note any relevant details, then redirect: \"This is helpful context - I can see what you've got here. For this exercise though, let's focus on a fresh scenario where you need to integrate with something new. Walk me through that discovery process.\"", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "Keep the conversation focused on the discovery exercise. If workspace design, permission models, or setup questions arise, note them for later: \"That's a great question - let's capture that for when we discuss workspace topology. For now, let's stay focused on how you'd find and use this API today.\"", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "When friction appears, let it play out. If they encounter a dead end, authentication failure, missing documentation, or express frustration, do not rush to help. Acknowledge it: \"I can see it's not straightforward - we can fix that. I'll note this down as a particular point of friction.\"", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "This friction is data. Broken documentation, dead links, abandoned wikis, \"I don't remember where this lives\" - these aren't failures of the exercise. They're proof points of the problem you're solving. The more visible the friction is in this baseline measurement, the more dramatic the improvement will be later.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "In a few weeks, after we complete the first two phases of onboarding this API, we’ll cut this down to a few minutes. The target is under 30 seconds to find the API, a few minutes to set up auth, and under 5 minutes to complete the workflow.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "When we present results to [executive sponsor], we'll show them this before state and the after state side by side. That's how we prove the value of what we're building. The systems they accessed during the Reverse Demo tell you exactly where API definitions need to be ingested from. If they checked AWS API Gateway, an internal wiki, and a Confluence page, those are your Phase 1 ingestion sources.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "The authentication friction they experienced tells you which auth patterns need guided setup in Phase 2, and the documentation gaps they hit tell you which request-level docs need to be prioritized. Quantifies the baseline: You now have objective data (time, systems, friction points) instead of subjective complaints. Reveals ingestion sources: You know exactly which systems contain the API definitions you need to consolidate in Phase 1. Creates empathy: The customer sees that you're interested in understanding their real workflow, not just pitching features. Builds the narrative: When you show executives a 45-minute struggle compressed into 5 minutes, they understand the value immediately. No abstract ROI calculations needed.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "Insights shortens mean time to detection and diagnosis by providing automatic endpoint inference, error aggregation, and latency views with no custom dashboards. Repro Mode turns real failing calls into executable requests in Request Builder, so teams can diagnose and validate fixes faster within Postman. Alerts integrate with Slack to keep error-rate regressions visible without additional tooling. Insights complements (not replaces) Phase 1–4 work: it points to hotspots while Path A establishes the hub, consumable documentation, tests, and visibility.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "After deployment, verify endpoints appear in the Insights app. Use the Overview, Errors, Latency, and Endpoints tabs to confirm traffic is flowing and endpoint inference is active. Reference: Insights app overview. Use the Endpoints tab to inventory discovered endpoints per service; filter by host/method/status to prioritize ingestion. Use “Save to Collections” from Insights (Endpoints) to seed canonical collections for top endpoints. Assign 2+ maintainers, configure environments (Dev/QA/UAT), and publish one stable collection.", "label": "positive", "surface": "longform", "topic": "on", "source": "path-a-playbook", "generator": "human", "mimicry": false}
{"text": "When sales brings CSE into an account with the right inputs, we can do real work. By \"right inputs\" I mean platform engineering leadership engaged, a concrete technical initiative on the table, and a team willing to work from their actual workflow instead of asking for a generic product tour. When that happens, CSE can execute and produce something repeatable. When it doesn't, we may end up telling the wrong story to the wrong room.", "label": "positive", "surface": "longform", "topic": "on", "source": "cse-v12-dispatch", "generator": "human", "mimicry": false}
{"text": "Contoso is a good example of the first case. Once the conversation got narrowed to a real pilot, the work became concrete fast: candidate service, bill of materials, CI/CD path, Lambda or other runtime, API gateway integration, and how contract tests, smoke tests, and actions workflows should be proofed with a safe non-prod rollout. That is the kind of engagement we should want. It's not speculative; it's a technical initiative with an owner and a path to implementation.", "label": "positive", "surface": "longform", "topic": "on", "source": "cse-v12-dispatch", "generator": "human", "mimicry": false}
{"text": "Actionable scoping, clear steps and ownership on both sides of the table, and a mutual agreement to produce a case study output have Contoso poised to be our first v12 hero story within the next few weeks; and they're not the only ones. Northwind is the same pattern at a larger scale. The inputs were strong. Platform leadership showed up. There's a real initiative around their developer portal and end-to-end workflow automation. The ask isn't \"show us Postman.\" The ask is \"show us how Postman, AI, design, governance, CI/CD, monitoring, and enablement fit into the platform we are already building.\" They came to us for consultancy, and consultancy is what they've got; CSE was able to dive headfirst into showing the implementation pattern, mapping the workflow, and will soon hand over a kit the customer can extend, paired with customized training to help the end users embrace the new world.", "label": "positive", "surface": "longform", "topic": "on", "source": "cse-v12-dispatch", "generator": "human", "mimicry": false}
{"text": "Fabrikam is probably the cleanest front-end example of the pattern. The motion improved as soon as the conversation shifted away from feature demo (\"show us Postbot\") toward the holistic v12 story (\"let's talk about Agent Mode and what it needs to be most powerful, tight integration into your source code and cloud service provider\"). We're currently working to spin up an exact copy of their SDLC so that we can show them the full end-to-end implementation in their terms next week, and we'll hand them exactly what they need to either scale it out on their own or hand it off to Professional Services. We expect this to deliver widespread, immediate value, and a customer story should soon follow.", "label": "positive", "surface": "longform", "topic": "on", "source": "cse-v12-dispatch", "generator": "human", "mimicry": false}
{"text": "The takeaway for me is this: the V12 story is strongest when we tell it as infrastructure, not as a feature bundle. If the audience is right and the initiative is real, CSE can turn that story into something concrete: an implementation, a kit, a success story, and measurable adoption. If those conditions aren't there, we should be disciplined enough to wait until they are, this is our path to a repeatable machine that carves out Postman's place as irreplaceable development infrastructure with each and every Enterprise customer.", "label": "positive", "surface": "longform", "topic": "on", "source": "cse-v12-dispatch", "generator": "human", "mimicry": false}
{"text": "CSEs are value engineers. We work side-by-side with customer engineers in co-execution sessions, turning ambiguity into clarity and paralysis into action. We don't advise from the sidelines, we don't demo features and hope they stick, and we don't assume the customer understands what Postman Enterprise can actually do for their engineering organization.", "label": "positive", "surface": "longform", "topic": "on", "source": "cse-charter", "generator": "human", "mimicry": false}
{"text": "We co-execute: build working implementations, prove feasibility and impact in days rather than quarters, and document value objectively upon delivery. Then we hand it off, to the customer's own team, to Professional Services for paid implementation, or to a TAM for ongoing support.", "label": "positive", "surface": "longform", "topic": "on", "source": "cse-charter", "generator": "human", "mimicry": false}
{"text": "Target: Measurable proof of ROI within 60 days. A value artifact that Sales and leadership can use to power renewal, expansion, and PS pipeline conversations. The problem: Customers buy Postman for user and data governance before understanding the engineering value. They nearly always fail to pivot from PLG value (user-driven behavior, collections, manual testing, personal workspaces) into the far more impactful and measurable systems of enterprise value that are independent of individual user behavior. When value-per-user is driven by individual behavior, license spend and expansion remain forever under scrutiny.", "label": "positive", "surface": "longform", "topic": "on", "source": "cse-charter", "generator": "human", "mimicry": false}
{"text": "The solution: CSE co-executes with customer engineers to build working, small-scale proof-of-value implementations that embed Postman as infrastructure, API catalog population, automated contract and smoke testing in CI/CD, governance enforcement, service discovery. This prevents \"pilot purgatory\" (Gartner: 30%+ of POCs abandoned) by forcing integration, data readiness, and measurable success criteria from day one.", "label": "positive", "surface": "longform", "topic": "on", "source": "cse-charter", "generator": "human", "mimicry": false}
{"text": "CSE activates the demand that makes PS viable. Customers rarely pursue large-scale SOW engagements without first experiencing the product through small, surgical implementations. CSE creates internal champions, proves value patterns, and builds the confidence necessary to justify and execute paid professional services. Without that activation layer, PS either stalls on scoping or fails to get the traction necessary to close a contract.", "label": "positive", "surface": "longform", "topic": "on", "source": "cse-charter", "generator": "human", "mimicry": false}
{"text": "TAMs provide ongoing technical support and consultation as paid staff augmentation. In the short term, TAMs and CSEs operate as one team due to capacity constraints. As the function scales, TAMs will transition to accounts that pay for ongoing augmentation. CSE focuses on the initial high-intensity engagement: prove value, build the pattern, hand off. TAMs maintain and extend.", "label": "positive", "surface": "longform", "topic": "on", "source": "cse-charter", "generator": "human", "mimicry": false}
{"text": "Discover. Identify what's deployed (via API gateway integration, Insights agent, or repo scanning). Understand the customer's infrastructure: SCM, CI/CD, cloud provider, auth patterns, deployment topology. Onboard. Ingest API specs into Spec Hub. Generate collections (baseline, contract, smoke). Configure environments. Link workspaces to repos. Populate the API catalog so services are discoverable in seconds instead of hours.", "label": "positive", "surface": "longform", "topic": "on", "source": "cse-charter", "generator": "human", "mimicry": false}
{"text": "Default: All incoming accounts over $250K will have a CSE assigned where capacity allows. AEs supporting these accounts can request post-sale technical support through the intake portal. What Qualifies for CSE. Engage CSE when all of these are true: the goal is technical adoption, not SSO setup, not onboarding, not break/fix; a named technical lead on the customer side has dev systems access and will co-work with the CSE; there's a clear desire for transformation (not just \"help us use Postman more\"); and the scope fits a success sprint or play.", "label": "positive", "surface": "longform", "topic": "on", "source": "cse-charter", "generator": "human", "mimicry": false}
{"text": "This document defines the North Star for Customer Success Engineering. Its purpose is to clearly articulate the destination we are working toward and the strategic logic behind the function. It is intentionally written at a strategic level. The goal is to establish where we are going and why it matters, not to prescribe every operational detail of how we will get there.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-north-star", "generator": "human", "mimicry": false}
{"text": "Execution will happen through focused quarterly plans and operating documents that translate this vision into specific actions. Given the pace of change at Postman, we will avoid over-engineering documentation and instead stay nimble, refining our approach as we learn from customer deployments.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-north-star", "generator": "human", "mimicry": false}
{"text": "Customer Success Engineering exists to increase durable revenue by embedding Postman from design to deployment, powering key API steps in software development, modernization and migration. Postman is already widely loved by developers. Historically, we tried to convert that love into enterprise value by encouraging individual behaviour change and collaboration inside Postman Enterprise. This approach had limited impact because it relied on the hardest variable to change: human behaviour.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-north-star", "generator": "human", "mimicry": false}
{"text": "The next big advantage is structural. Because developers already use Postman, organizations can standardize how APIs are designed, tested, governed, and consumed through a tool their teams have already adopted rather than forcing new tooling or process.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-north-star", "generator": "human", "mimicry": false}
{"text": "By integrating Postman across the software development toolchain and enforcing standards through automated testing, linting, and policy checks in CI/CD, customers can operationalize how APIs are built and governed at scale without relying on manual enforcement.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-north-star", "generator": "human", "mimicry": false}
{"text": "When Postman is embedded in the automation that ships and governs APIs, it becomes infrastructure rather than optional tooling. Renewal reflects operational dependency and expansion follows as usage scales with every new service and developer.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-north-star", "generator": "human", "mimicry": false}
{"text": "Customer Success Engineers are deployed when there is a clear, qualified path to embedding Postman into a customer’s engineering workflows. This means the organization has both executive sponsorship and a defined initiative to operationalize Postman as part of how APIs are built, governed, and deployed.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-north-star", "generator": "human", "mimicry": false}
{"text": "In practice, CSE engagement begins when a customer is ready to move beyond feature exploration and embed Postman into the systems that power their software development lifecycle. Expanding Postman as a build and modernization platform, scaling usage across multiple teams through management-plane capabilities such as governance, cataloging, and automated quality enforcement.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-north-star", "generator": "human", "mimicry": false}
{"text": "Connecting Postman into the broader engineering ecosystem, including cloud-native platforms, internal developer platforms, CI/CD pipelines, gateways, and other components of the software development toolchain. When engaged, CSEs act as the technical authority for Postman adoption, designing the architecture for how Postman integrates into the customer’s engineering ecosystem and guiding the organization through the adoption journey. They work directly with platform and engineering leaders to define the implementation approach, activate pilot use cases, and validate the operating model.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-north-star", "generator": "human", "mimicry": false}
{"text": "CSE engagement continues as long as there is clear potential to deepen Postman’s role in the customer’s development lifecycle. In some cases, this may span multiple initiatives over an extended period of time. The objective is to drive the customer to a durable, self-sustaining adoption state.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-north-star", "generator": "human", "mimicry": false}
{"text": "Durable platform adoption. Integrate their API toolchain, build standards into rulesets, and enforce adherence through automation. This creates differentiated outcomes for buyers while strengthening the underlying activity plane. Success stories and repeatable patterns. Each engagement will generate: customer-validated success stories, as well as documented implementation patterns and templates. Produces credible proof for Sales and Marketing and technical insight to refine the Product roadmap.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-north-star", "generator": "human", "mimicry": false}
{"text": "Services and expansion pathways. CSE work creates opportunities for: Professional Services delivery at scale, paid ongoing technical support models, and product-led expansion. Capacity is continually reallocated to the highest-impact opportunities. Our impact scales through producing repeatable patterns and success stories, not from expanding headcount indefinitely.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-north-star", "generator": "human", "mimicry": false}
{"text": "Solution Engineering focuses on technical exploration, evaluation, and validation. They demonstrate what is possible and help customers envision future-state value. The objective is not coverage. The objective is to validate strategic hypotheses and help Postman convert widespread developer usage into durable enterprise dependence and long-term revenue growth.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-north-star", "generator": "human", "mimicry": false}
{"text": "Meet customers where they are, and build compounding value. Enhance existing workflows by default, replace when pain is high, and expand coverage over time. Automation is the deliverable, not the byproduct. Every engagement produces reusable infrastructure. This is our only viable path to break into the 7+ figure enterprise market effectively.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-platform-playbook", "generator": "human", "mimicry": false}
{"text": "Most organizations are not ready to apply automation across their full API estate immediately. This phase proves the operating model on a single service with a usable specification and gives the customer a tangible example of the target future state.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-platform-playbook", "generator": "human", "mimicry": false}
{"text": "Our focus is building automation that will scale. During this initial phase, we will build out “spec-driven automation” that triggers a cascading series of steps when a specification is created or updated in a git repository. If it's a new service, then it must get integrated with the git repository using Postman's new native git integration. Taxonomy defaults to the name of the repository folder name.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-platform-playbook", "generator": "human", "mimicry": false}
{"text": "Environments: Provision what is deterministic. Mock environments can always be generated as the servers are Postman-owned, but localhost, dev/staging and prod may require manual input. Ecosystem link onboarding: Programmatic system environment linking, workspace to SCM linking, insights deployment and onboarding; anything that makes API catalog ingestion and population at scale feasible.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-platform-playbook", "generator": "human", "mimicry": false}
{"text": "We will collaborate in a sandbox environment. Once successful, we update the script to point to their production environment. We package this up for the customer and proceed to Phase 2. Producer Workspace Standardization: All spec-ready services will follow a consistent Service Repo <> Workspace mapping with standardized naming, ownership, and tagging.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-platform-playbook", "generator": "human", "mimicry": false}
{"text": "Map Service Creation: Identify where new services are created (ex. Internal developer platform) and the subsequent workflow. Map where Postman fits in Metadata Enrichment: Enhance the automation with any additional metadata we can expect from new service provisioning (ex. owner, runtime environments, etc)", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-platform-playbook", "generator": "human", "mimicry": false}
{"text": "Spec Reconciliation: Services WITH specs -- compare gateway runtime to spec, flag drift. Services WITHOUT specs -- resolve baseline specs from definitions elsewhere and consolidate them in a high-visibility location. Catalog Population: Bulk-ingest discovered services into API Catalog via Bifrost. Auto-connects using cloud provider credentials, discovers all services automatically.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-platform-playbook", "generator": "human", "mimicry": false}
{"text": "Govern: Apply baseline governance rules (Spectral linting, contract test generation) to all cataloged services. Visibility first, enforcement second. Score services, don't block them. Remediation Prioritization: Use Agent Mode + Catalog insights to rank which legacy services need full Phase 1 treatment vs passive monitoring. Not everything needs an active rebuild", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-platform-playbook", "generator": "human", "mimicry": false}
{"text": "From a change management perspective, everything that we've done up to this point does not rely on enablement-driven changes to behaviour or any user knowledge at all. In fact, quite the opposite: it organically promotes the adoption of more tightly integrated, more robust, higher-value user behaviours purely by reducing friction.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-platform-playbook", "generator": "human", "mimicry": false}
{"text": "Enterprises don’t need to rush to retire old assets or force migrations; users naturally follow the path of least resistance. Legacy resources will die off over time. Producer Enablement: Walk through the golden path workflow end-to-end: service creation -> spec in Git -> auto-generated collections, mocks, and tests -> CI/CD enforcement -> monitors. Highlight what Postman unlocks at each step and reinforce collaborative best practices.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-platform-playbook", "generator": "human", "mimicry": false}
{"text": "Consumer Enablement: Enable consumers to discover and integrate with APIs using generated collections and environments. Show how to fork collections, test against mock or runtime, and stay in sync with producer updates. Platform Enablement: Enable platform teams to operate and evolve the system: manage governance and automation, own the golden path, and introduce Private API Network when ready to curate and organize internal APIs for discovery.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-platform-playbook", "generator": "human", "mimicry": false}
{"text": "Postman is widely loved by developers. Historically, we’ve tried to convert that love into enterprise value by encouraging individual behaviour change and collaboration inside Postman Enterprise. This approach had limited impact because it relied on the hardest variable to change: human behaviour.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-gtm-guidance", "generator": "human", "mimicry": false}
{"text": "We’ve learned our real advantage is even bigger. Because developers already use Postman, organizations can standardize how APIs are designed, tested, governed, and consumed through a tool their teams have already adopted rather than forcing new tooling or process.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-gtm-guidance", "generator": "human", "mimicry": false}
{"text": "By integrating Postman across the software development toolchain and enforcing standards through automated testing, linting, and policy checks in CI/CD, customers can operationalize how APIs are built and governed at scale without relying on manual enforcement.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-gtm-guidance", "generator": "human", "mimicry": false}
{"text": "When Postman is embedded in the automation that ships and governs APIs, it becomes infrastructure rather than optional tooling. Renewals become easy, and expansion happens organically as usage automatically scales with every new service. Sales needs to get CSE into the room with the people who can change how APIs are built, governed, tested, discovered, and shipped across the customer’s organization.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-gtm-guidance", "generator": "human", "mimicry": false}
{"text": "The best customer conversation is with someone who owns org-wide automation: Platform Engineering, DevOps, DevEx, API Platform, API Governance, Cloud Platform, Architecture, or Engineering Productivity. Most customers already have pockets of Postman usage. The bigger problem is that API work still happens through disconnected systems: specs in one place, tests somewhere else, docs drift, governance lives in docs, catalogs are incomplete, and CI/CD does not consistently enforce standards.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-gtm-guidance", "generator": "human", "mimicry": false}
{"text": "We embed Postman into your engineering workflow so API standards, testing, and governance happen automatically instead of relying on manual behaviour. 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.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-gtm-guidance", "generator": "human", "mimicry": false}
{"text": "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": "Engagements are focused and hands-on. CSEs will prove the model with a real service, establish a repeatable pattern, and set you up to scale it across your organization. Our focus is building automation that scales. We partner with customers to build “spec-driven automation” that triggers a cascading series of steps whenever a spec is created or updated in a git repository.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-gtm-guidance", "generator": "human", "mimicry": false}
{"text": "If it's a new service, then it will also get integrated with the git repository using Postman's new native git integration. Taxonomy defaults to the name of the repository folder. Collections: Generate and/or update 3 types of collections from the specification: canonical (source of truth for dev and collab), smoke (test) and contract (test).", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-gtm-guidance", "generator": "human", "mimicry": false}
{"text": "Engagements are focused and hands-on. CSEs will prove the model with a real service, establish a repeatable pattern, and set you up to scale it across your organization. Are there parts of your API workflow you wish just handled themselves? Perhaps some things you’ve tried to automate but couldn’t quite crack? That’s exactly where CSEs shine.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-gtm-guidance", "generator": "human", "mimicry": false}
{"text": "Our most mature customers are solving this by embedding Postman into their engineering workflow so API standards, testing, and governance happen automatically instead of relying on manual behaviour.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-gtm-guidance", "generator": "human", "mimicry": false}
{"text": "Next quarter, we will continue to prove out the motion, increase throughput via enablement to the organization, and implement a continuous feedback loop / constraint identification. While we delivered measurable value with several customers in Q1, we did not reach our stretch target of 5 customer-validated success stories on SLG use cases.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-q1-fy27-retro", "generator": "human", "mimicry": false}
{"text": "In Q1, we operationalized the core motions required to execute our strategy. Starting from the target output, we worked backwards to define the customer progression model, including the stages customers move through and the prerequisites required to begin engagement. We then formalized these motions into structured playbooks with defined stages, exit criteria, and measurable progression paths.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-q1-fy27-retro", "generator": "human", "mimicry": false}
{"text": "To improve scalability and reduce time to value, we developed reusable assets and implementation patterns that future CSEs can leverage across engagements. We also codified the work into Jira, making engagement progress visible through standardized stages and workflow tracking. To reduce administrative overhead, we built agents to help populate and maintain tickets automatically.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-q1-fy27-retro", "generator": "human", "mimicry": false}
{"text": "In parallel, we implemented automation around executive briefings and engagement reporting, reducing manual preparation work while improving consistency and visibility into customer progress. In Q1, we built enablement content around our core capabilities and customer motions, initially targeting Sales before pivoting toward SE-focused enablement to improve technical qualification. We also refined the CSE interview process and case study exercises to improve hiring quality. Candidate quality has been strong, although overall recruiting velocity remained slower than expected.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-q1-fy27-retro", "generator": "human", "mimicry": false}
{"text": "We delivered multiple enablement sessions during the quarter, but most functioned as informational sessions rather than operational change mechanisms. We did not implement formal follow-up measurement, such as AE/SE awareness surveys or qualification tracking, making it difficult to measure retention or impact. Anecdotally, many international teams either did not attend the sessions or still lacked a clear understanding of the CSE motion and the types of engagements we support.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-q1-fy27-retro", "generator": "human", "mimicry": false}
{"text": "The primary learning from Q1 is that there are still significant gaps in GTM’s understanding of 1) what types of engagements CSEs support, and 2) how we bring our v12/platform story to life. These gaps affect the number of qualified use case activation opportunities that we can work on and hinder GTM’s transition to a true SLG motion.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-q1-fy27-retro", "generator": "human", "mimicry": false}
{"text": "In Q2, we want to enable through action, not just information. We will continue to reinforce the distinction and value of the new motion and proactively identify strong opportunities, rather than relying on inbound demand from Sales.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-q1-fy27-retro", "generator": "human", "mimicry": false}
{"text": "Q2 is about increasing throughput through proactive engagement. The next 60 days should be extremely concrete: prioritize the portfolio, declare the activation plan, execute the work, and turn at least one activation into reusable proof. Sales remains accountable for the commercial strategy, stakeholder access, and account ownership. CSEs are accountable for the technical work required to turn qualified customer problems into activated Postman workflows. That means helping the account team identify gaps, shaping the technical point of view, supporting stakeholder conversations where CSE credibility helps, and then owning use case activation once the right stakeholders are engaged.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-q2-kpis", "generator": "human", "mimicry": false}
{"text": "Which named accounts are ready for activation. Which accounts need nurturing before CSE can be effective. Which use cases they are trying to activate. Which gaps need help from Sales, Product, Support, or Professional Services. How they expect to exceed their KPIs. A use case activation engagement is completed when CSE has helped a customer move from a qualified problem to a working Postman-powered workflow in their environment.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-q2-kpis", "generator": "human", "mimicry": false}
{"text": "The engagement has a clearly defined customer problem or desired outcome, activates Enterprise-differentiated capabilities or integrates Postman into the customer engineering ecosystem, and has documented proof points, build log, value realized, and next step. Generic training, feature walkthroughs, unscoped discovery, troubleshooting without activation, or internal-only proof that was not validated with the customer. A success story is produced when a completed use case activation has been turned into a reusable customer narrative that clearly explains the transformation CSE helped deliver.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-q2-kpis", "generator": "human", "mimicry": false}
{"text": "The right stakeholders are engaged and we see a clear path to activating one or more meaningful use cases. We have access to the people who own the problem, Postman is well positioned to solve it, and CSE can start scoping or executing activation work now. Build the activation plan and move quickly. These are the primary candidates for the 3+ use case activation KPI. The account has meaningful potential, but we are not yet in front of the right people or the activation path is not fully clear.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-q2-kpis", "generator": "human", "mimicry": false}
{"text": "These accounts require partnership with the AE, SE, or EM to determine how we get in front of the right stakeholders, tell the platform story, validate the problem, and create a path to activation. Shape the technical point of view, identify stakeholder gaps, support outreach and discovery where useful, and work with the account team to move the account into P1. We do not see a credible path to activation in the near future.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-q2-kpis", "generator": "human", "mimicry": false}
{"text": "For each target account, develop a clear technical point of view on where Postman can create more value. Understand where Postman is used today. Identify where Postman is not used but should be. Look for gaps in governance, discoverability, API quality, automation, collaboration, migration, or scale. Connect the current customer workflow to a higher-value Postman platform workflow. Define the problem we believe Postman can help solve. Bring technical credibility into account planning and stakeholder conversations.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-q2-kpis", "generator": "human", "mimicry": false}
{"text": "Partner with the AE on the account strategy and agree on where CSE can create the most leverage. Get in front of the customer through discovery, technical workshops, platform-story conversations, health checks, or use case activation sessions. Pitch the Postman platform story in the context of the customer’s workflow, not as a generic product overview. Use your technical point of view to create urgency, validate the problem, and show the customer what better looks like.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-q2-kpis", "generator": "human", "mimicry": false}
{"text": "Convert interest into a concrete next step: deeper discovery, activation plan, workshop, proof, implementation session, or value review. Keep the account moving. If the customer stalls, identify the constraint and ask for help. Exit criteria: the account has forward motion. We have either advanced a customer conversation, validated a use case, created a path to activation, or learned why the account is not ready. The next step is clear, owned, and scheduled.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-q2-kpis", "generator": "human", "mimicry": false}
{"text": "Trust your judgement. CSEs know our product inside and out. If you disagree with an account strategy, we encourage you to speak up and/or raise this to CS Leadership for review.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-q2-kpis", "generator": "human", "mimicry": false}
{"text": "Customer Success Engineers (CSEs) are not assigned to accounts in perpetuity. CSEs are deployed when there is a clear, qualified path to embedding Postman into a customer’s engineering workflows. In practice, CSE engagement begins when a customer is ready to move beyond feature exploration and embed Postman into the systems that power their software development lifecycle. The request is submitted by the Solution Engineer and tied to a clearly defined advanced use case that embeds Postman into engineering workflows through systems and automation.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-factory-operations", "generator": "human", "mimicry": false}
{"text": "The use case should be expressible in one sentence and typically involve activation of advanced Enterprise-only capabilities such as API Catalog, API Governance, or Private API Network. There should be success criteria, a rough timeline, and explicit customer intent to execute. CSE should begin where there is a real path to structural adoption, not general product interest, feature questions, or technical support. Requiring SE-backed use case clarity improves qualification quality and ensures CSE time is spent on customers who are ready to get meaningful work done.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-factory-operations", "generator": "human", "mimicry": false}
{"text": "Executive sponsorship is what keeps the work moving when dependencies, tradeoffs, or blockers appear. There is at least one meaningful customer-side technical owner or team to engage with, such as platform engineering, DevEx, API leadership, or the team that owns the relevant workflow or integrated system. If the use case involves another tool, such as CI/CD, gateway, or internal developer platform, the team that owns that system must be involved.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-factory-operations", "generator": "human", "mimicry": false}
{"text": "CSE is a use case activation team, not white-glove technical support. Without committed customer capacity, the engagement becomes discussion without movement. The customer needs hands-on pilot execution, integration expertise, and a repeatable pattern documented that they can highlight to scale out the impact. It is not generic adoption help, broad program management, or feature exploration. This protects role clarity. CSE activates, proves, and prescribes. Solution Engineers align the solution through discovery, validation, and technical support for expansion.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-factory-operations", "generator": "human", "mimicry": false}
{"text": "Customer Success Engineers activate the solution by embedding it into production workflows. Technical Account Managers sustain the solution through paid, ongoing operational guidance. Activate the API Catalog for Platform Leaders and improve API discoverability across teams. A CSE request should be declined, deferred, or redirected if any of the following are true: The ask is generic adoption help, use case exploration, or heavily focused on end user enablement", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-factory-operations", "generator": "human", "mimicry": false}
{"text": "There is no believable use case tied to workflow embedment and/or advanced feature activation (API Governance, API Catalog). Is there a clearly defined advanced use case to activate? Has the Solution Engineer verified that this is real CSE-shaped work? Can we describe the use case in one sentence, including the workflow we are trying to change? Is there an executive sponsor with authority to keep the work moving?", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-factory-operations", "generator": "human", "mimicry": false}
{"text": "Understand the customer’s current workflow, tooling, architecture, pain points, ownership, and existing Postman usage. Identify the target workflow they want to create. Determine where Postman should fit and what systems or teams are involved. Identify blockers, dependencies, and environment constraints. Define what success would look like in simple, measurable terms. Current state and future state are documented. The workflow change is clear. The systems, owners, and dependencies involved are known.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-factory-operations", "generator": "human", "mimicry": false}
{"text": "Success signals are defined clearly enough to judge whether the use case is successfully activated. A technical hypothesis is converted into a customer-approved pilot that is small enough to move quickly and meaningful enough to prove value. Review the proposed approach with the sponsor and technical team. Pressure test the scope. Cut out anything nonessential. Define exactly what the pilot will cover, what it will not cover, who is involved, which environments are needed, what prerequisites must be in place, and what proof of value we are aiming for.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-factory-operations", "generator": "human", "mimicry": false}
{"text": "Position a case study upon successful completion of pilot. Set the timeline, owners, and next steps. Customer sponsor and technical owners approve the pilot. Pilot scope is narrow enough to execute in <90 days. In-scope systems, environments, and owners are agreed. Technical prerequisites and dependencies are understood. Success criteria are clear and objective. Customer has agreed to a case study if the success criteria are met. Immediate next steps are scheduled.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-factory-operations", "generator": "human", "mimicry": false}
{"text": "Postman proves the concept internally first and prepares reusable assets that help the customer get to value faster. Build and test the pilot pattern in Postman’s own environment or a controlled setup first. Prove that the concept works; produce scripts, templates, collections, rulesets, setup steps, and supporting assets. Package the work so the customer can drag, drop, adapt, and implement faster. Catalog artifacts internally for reuse with future customers.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-factory-operations", "generator": "human", "mimicry": false}
{"text": "Remove blockers quickly and keep the work moving. Make sure the customer team is doing the work and internalizing the why, not just watching it happen. Customer-owned technical work has been completed. Required setup and integration blockers are resolved or under control. The use case is operating in the customer’s system, not just in Postman’s internal proof environment. Measurable increases in usage metrics correlated with the use case being targeted.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-factory-operations", "generator": "human", "mimicry": false}
{"text": "Prepare a clear case study story or internal success story. Define the best next motion: customer self-service, Professional Services, partner rollout, new CSE engagement, or transition back to Sales. A repeatable implementation kit exists and is usable by others. The pattern is documented clearly enough to scale. A credible case study or internal success story has been documented. The next motion is clear enough for Sales, Services, partners, or the customer to act on.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-factory-operations", "generator": "human", "mimicry": false}
{"text": "The use case can continue without day-to-day CSE ownership and CSE capacity is freed for the next high-value engagement. Hand off the proven pattern to the next owner, whether that is the customer team, Professional Services, a partner, or a new scoped CSE phase. Transfer the implementation kit, technical context, open risks, and next steps. Confirm who owns the next phase and when the next checkpoint will happen.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-factory-operations", "generator": "human", "mimicry": false}
{"text": "Exit only when continuity is protected. The use case no longer depends on day-to-day CSE involvement, or ownership has been explicitly accepted by the next motion. Assets, context, and open risks are transferred. The next action is scheduled. Removing this workflow would cause the customer’s operations to break or degrade. Tactically, we will leave the account with an activated use case, a repeatable implementation kit, and a credible technical value story.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-factory-operations", "generator": "human", "mimicry": false}
{"text": "Sales can point to real usage, real value, and real progress. The engagement produced the scripts, templates, setup steps, architecture guidance, guardrails, and rollout notes needed for the customer, Professional Services, or partners to scale the use case. The work does not end as a one-off pilot. It will now be much easier to repeat across more teams, services, or business units. For resource constrained customers, this presents a strong opportunity to sell Professional Services to scale value further.", "label": "positive", "surface": "longform", "topic": "on", "source": "csri-factory-operations", "generator": "human", "mimicry": false}
{"text": "I have identified several action items from the meeting and created the appropriate tickets to track them.", "label": "negative", "surface": "jira_standalone", "topic": "on", "source": "seed", "generator": "ai_seed", "mimicry": false}
{"text": "I was unable to determine the appropriate owner for this ticket; please advise on how to proceed.", "label": "negative", "surface": "jira_standalone", "topic": "on", "source": "seed", "generator": "ai_seed", "mimicry": false}
{"text": "This is an automated update from the CSE Engagement Tracker.", "label": "negative", "surface": "jira_standalone", "topic": "on", "source": "seed", "generator": "ai_seed", "mimicry": false}
{"text": "Auto-generated summary: the ticket has been in Technical Discovery for 14 days.", "label": "negative", "surface": "jira_standalone", "topic": "on", "source": "seed", "generator": "ai_seed", "mimicry": false}
{"text": "The customer has not responded in over 7 business days. Kindly follow up at your earliest convenience.", "label": "negative", "surface": "jira_standalone", "topic": "on", "source": "seed", "generator": "ai_seed", "mimicry": false}
{"text": "Please be advised that the Executive Sponsor field has not yet been populated for this engagement.", "label": "negative", "surface": "jira_standalone", "topic": "on", "source": "seed", "generator": "ai_seed", "mimicry": false}
{"text": "The follow-on engagement will commence once the current phase reaches completion.", "label": "negative", "surface": "jira_standalone", "topic": "on", "source": "seed", "generator": "ai_seed", "mimicry": false}
{"text": "Customer has been quiet for 11 business days. Any update?", "label": "negative", "surface": "jira_standalone", "topic": "on", "source": "seed", "generator": "ai_seed", "mimicry": false}
{"text": "Filled in Executive Sponsor and Technical Counterpart based on the meeting notes.", "label": "negative", "surface": "jira_standalone", "topic": "on", "source": "seed", "generator": "ai_seed", "mimicry": false}
{"text": "What's the latest on this?", "label": "negative", "surface": "jira_standalone", "topic": "on", "source": "seed", "generator": "ai_seed", "mimicry": false}
{"text": "Reaching out to follow up on this engagement and confirm next steps.", "label": "negative", "surface": "slack_dm", "topic": "on", "source": "seed", "generator": "ai_seed", "mimicry": false}
{"text": "Please let me know if you have any questions or concerns regarding the above.", "label": "negative", "surface": "slack_dm", "topic": "on", "source": "seed", "generator": "ai_seed", "mimicry": false}
{"text": "This should be the right target based on the information provided.", "label": "negative", "surface": "jira_standalone", "topic": "on", "source": "seed", "generator": "ai_seed", "mimicry": false}
{"text": "We have identified the next step and are moving forward accordingly.", "label": "negative", "surface": "jira_standalone", "topic": "on", "source": "seed", "generator": "ai_seed", "mimicry": false}
{"text": "I wanted to touch base regarding the status of the engagement and gather an update on progress.", "label": "negative", "surface": "slack_dm", "topic": "on", "source": "seed", "generator": "ai_seed", "mimicry": false}
{"text": "Summary of progress to date: (1) ticket filed, (2) AE engaged, (3) awaiting customer confirmation.", "label": "negative", "surface": "jira_standalone", "topic": "on", "source": "seed", "generator": "ai_seed", "mimicry": false}
{"text": "The customer is currently evaluating the proposed solution and will provide feedback shortly.", "label": "negative", "surface": "jira_standalone", "topic": "on", "source": "seed", "generator": "ai_seed", "mimicry": false}
{"text": "Customer wants us to prepare a comprehensive technical deep-dive ahead of the upcoming workshop.", "label": "negative", "surface": "jira_standalone", "topic": "on", "source": "seed", "generator": "ai_seed", "mimicry": false}
{"text": "Customer has expressed interest in exploring the platform further during the next scheduled sync.", "label": "negative", "surface": "slack_dm", "topic": "on", "source": "seed", "generator": "ai_seed", "mimicry": false}
{"text": "Another one for you -- let's get this moved before end of week.", "label": "negative", "surface": "jira_standalone", "topic": "on", "source": "seed", "generator": "ai_seed", "mimicry": false}
{"text": "One more for the pile, same owner as the last two.", "label": "negative", "surface": "jira_standalone", "topic": "on", "source": "seed", "generator": "ai_seed", "mimicry": false}
{"text": "Same goes for this one -- no movement since last Friday.", "label": "negative", "surface": "jira_standalone", "topic": "on", "source": "seed", "generator": "ai_seed", "mimicry": false}
{"text": "Customer's workshop is coming up in late May — we should prepare the demo environment in advance.", "label": "negative", "surface": "slack_dm", "topic": "on", "source": "seed", "generator": "ai_seed", "mimicry": false}
{"text": "Waiting on the contracting team to finalize the paperwork before we can kick off the engagement.", "label": "negative", "surface": "jira_standalone", "topic": "on", "source": "seed", "generator": "ai_seed", "mimicry": false}
{"text": "Moved to Pilot Validation based on the evidence. Source: https://postmanlabs.atlassian.net/browse/CSE-123 (comment from 2026-05-01).", "label": "negative", "surface": "jira_standalone", "topic": "on", "source": "seed", "generator": "ai_seed", "mimicry": false}
{"text": "I do not see any outstanding blockers; however, we cannot proceed until the field is populated.", "label": "negative", "surface": "jira_standalone", "topic": "on", "source": "seed", "generator": "ai_seed", "mimicry": false}
{"text": "It appears that the most prudent course of action would be to await further instructions from the account team.", "label": "negative", "surface": "jira_standalone", "topic": "on", "source": "seed", "generator": "ai_seed", "mimicry": false}
{"text": "Hi team, I hope this message finds you well. I wanted to quickly sync on the following items.", "label": "negative", "surface": "slack_dm", "topic": "on", "source": "seed", "generator": "ai_seed", "mimicry": false}
{"text": "Hello everyone, just a friendly reminder that the above action items are still pending.", "label": "negative", "surface": "slack_dm", "topic": "on", "source": "seed", "generator": "ai_seed", "mimicry": false}
{"text": "This document provides a comprehensive overview of the engagement, including objectives, scope, and milestones.", "label": "negative", "surface": "longform", "topic": "on", "source": "seed", "generator": "ai_seed", "mimicry": false}
{"text": "hey Jo, I moved the Acme CSE ticket (CSE-85) into Technical Discovery since you're actively driving it. when you get a sec, can you drop the latest onto the ticket, current scope, customer side owners, and next step, so the stage and notes match where you actually are? thanks", "label": "negative", "surface": "slack_dm", "topic": "on", "source": "observed", "generator": "ai_seed", "mimicry": false}