<div class="content-intro"><p>Everpure (NYSE: P) has evolved from storage pioneer to data platform, closing fiscal 2026 with $3.7 billion in revenue, its first billion-dollar quarter, and accelerating growth into FY27. Our strategic agenda spans the companies defining the next era of technology - hyperscalers, AI labs, the AI hardware supply chain, data platform providers, and the broader AI ecosystem.</p> <p>This type of work—work that changes the world—is what the tech industry was founded on. So, if you're ready to seize the endless opportunities and leave your mark, come join us.</p></div><h1><strong>Proposal Tools Analyst</strong></h1> <h2><strong>Purpose</strong></h2> <p>The Apollo programme is replacing the many separate tools used at each sales stage with one operating model. In the Proposing stage, that means one new proposal platform that produces a single, standard customer business case. It replaces the self-service tools that today give different answers for the same customer scenario.</p> <p>The Proposal Tools Analyst lays the groundwork that makes this possible. You will work through the existing business case, TCO, RFX and proposal tools. You'll turn what you learn into one prioritised, traceable set of requirements. Then you'll make sure each old tool is retired safely.</p> <p>The role has three parts:</p> <ul> <li><strong>Understand the estate.</strong> Work with each tool owner to document what their tool does, what data it relies on, who uses it and why.</li> <li><strong>Define the platform.</strong> Turn that understanding into one set of system requirements that the build team works and tests against.</li> <li><strong>Retire safely.</strong> Switch off each old tool only once the new platform has been shown to cover what the field needs from it.</li> </ul> <h2><strong>What Success Looks Like</strong></h2> <ul> <li>Every proposal, business case and RFP tool in GSO is known to the programme. Each in-scope tool has a full document that its owner has checked.</li> <li>There is one requirements catalogue, kept in sync with the prototype. Every requirement traces back to the field need and the tool it came from.</li> <li>Requirements are prioritised with the Field Advisory Group and Proposal Track leads, so the build team works from one ranked list.</li> <li>Testing covers the documented requirements, and the Field Advisory Group has formally signed it off.</li> <li>Tools are retired on schedule without disrupting the field. Each retirement is signed off against a capability map, not a date.</li> <li>There is an agreed recommendation for RFP and RFQ tooling.</li> </ul> <h2><strong>What You'll Be Doing</strong></h2> <h3><strong>Discovery</strong></h3> <ul> <li>Build on the Apollo dashboard inventory with a detailed document for each tool: scope, functions, users, data, calculation logic, outputs and limits.</li> <li>Find tools that aren't recorded yet and get them submitted to the programme.</li> <li>Trace each tool's data sources, assumptions and hard-coded values. Flag overlaps, gaps and places where tools give different financial outputs.</li> </ul> <h3><strong>Requirements and Product Partnership</strong></h3> <ul> <li>Turn field needs and tool functions into clear, testable requirements, and feed them into the prototype as it changes.</li> <li>Decide what to rebuild, retire or combine, and record why.</li> <li>Work with Global Value Management to document TCO, cash flow and P&L requirements. Capture non-functional needs too, such as Salesforce write-back, governance, permissions and auditability.</li> <li>Work with the Business Platform Owner and DTG as the business-side counterpart. Help shape releases that let old tools be retired as early as possible.</li> </ul> <h3><strong>Testing and Decommissioning</strong></h3> <ul> <li>Make sure test scope and test cases map directly to the requirements. Take completed testing to the Field Advisory Group for sign-off.</li> <li>Own the capability map that links each old tool to the requirements that must be delivered before it can be switched off.</li> <li>Set exit criteria and transition paths with tool owners, and give Sales Enablement what they need for cutover training.</li> <li>Capture logic and content worth keeping before a tool is switched off.</li> </ul> <h3><strong>RFP Tooling</strong></h3> <ul> <li>Review how the field uses Responsive today and gather RFP and RFQ requirements.</li> <li>Compare Responsive with the alternatives, including building RFP responses into the new platform. Recommend an approach with cost, effort and timeline.</li> </ul> <h2><strong>Who You'll Work With</strong></h2> <ul> <li><strong>Programme and project managers:</strong> planning, reporting, risks and dependencies</li> <li><strong>Product owners and DTG:</strong> build order, design decisions and release planning</li> <li><strong>Tool owners:</strong> discovery, checking your documentation and agreeing retirement</li> <li><strong>Global Value Management:</strong> financial calculation logic and business case method</li> <li><strong>Field Advisory Group:</strong> real-world checks, prioritisation and test sign-off</li> <li><strong>Testing teams:</stro