Incident and Escalation Manager

Voice AI that resolves, not transfers. Most phone systems trap callers in menus and scripts. Vapi is the platform for deploying voice agents that know your business and can listen, adapt, and resolve in minutes. - The numbers: 1 billion calls. 1 million developers. 10x enterprise ARR growth - The customers: Amazon Ring, ServiceTitan, New York Life, Intuit, Kavak, and thousands more, from YC startups to the Fortune 500 - The news: a $50M Series B led by Peak XV Partners, with Bessemer Venture Partners, Kleiner Perkins, M12 (Microsoft's Venture Fund), Y Combinator, and our earlier backers. Total raised: $72M Incident and Escalation Manager Why this role exists Vapi runs voice AI infrastructure at tens of millions of minutes a month for enterprise customers who route business-critical traffic through us. When something breaks, it breaks in real time, in front of a customer's own customers, and often through a carrier dependency we don't fully control. Today the response is run by whoever is in the Slack thread. That works once. It does not scale, and it costs us renewals, engineering focus, and executive confidence every time it happens. This is the first dedicated hire for the function, and the job is to build it. You will design the program that runs our incident response, train the people who command incidents, and own the customer relationship through the weeks that follow a serious one. You own the pager and you work part of the rotation yourself, because the fastest way to build a program that works is to run inside it while you build it. You are not the engineer fixing the system. You are the person who builds the system so a trained bench can run it, and who takes a real turn on the pager. Building the program This is the core of the role. - Define what counts as an incident and what does not, with entrance and exit criteria that protect engineering from noise. - Author the severity model with response-time targets per level, so a SEV0 means the same thing Monday morning and Friday night. - Design how a live incident runs: the command structure, the update cadence, the single source of truth, the decision rights, and when the call gets escalated past the commander. Write it down so anyone on rotation runs it the same way. - Build and train the incident commander rotation. Build a realistic balance of hiring and utilizing existing resources across humans and AI to stand up the rotation. - Own the pager and work part of the rotation yourself - personally commanding incidents during your shifts and stepping your share down as the bench matures and proves out. Own how the rotation runs regardless of whose shift it is. - Stand up the incident tooling and on-call setup: paging, escalation policies, incident channels, status page, and the runbook library. - Build customer communication templates for each severity and channel, pre-approved so they are not written from scratch under pressure. - Govern the customer credit process with a clear approval chain, so financial decisions stop happening in ad hoc threads. - Stand up the metrics: resolution time, response velocity, escalation volume, RCA SLA adherence, and revenue protected. Report monthly in terms execs use to make resource decisions. - Build standing partnerships with engineering, support, the office of the CTO, legal, security, comms, and carrier operations before the next critical situation. - Train go-to-market, support, customer success, and engineering on where to bring customer-critical issues and how the function works. - Build a feedback loop so incident and escalation data shapes the engineering roadmap instead of dying in postmortems. After the incident - Own the customer-facing RCA. Translate engineering root cause into plain language that tells the truth and holds the relationship. Ship it within the SLA we commit to. - Run the blameless post-incident review. Drive action items to named owners with dates, and track them to closure instead of letting them die i