jumpstart-mode 1.1.13 → 1.1.14

package/.jumpstart/skills/gtm-ai-gtm/references/enterprise-ai-objections.md

@@ -0,0 +1,80 @@
+# Enterprise AI Objections
+
+Use this reference when the user needs objection handling, messaging for enterprise AI buyers, or guidance on how to demo action-taking AI without creating unnecessary fear.
+
+## The core objection
+
+The real enterprise objection is often not "will the AI ever fail?" It is "who owns the failure when it does?"
+
+Frame trust around operational accountability:
+
+1. `L1 response`: who monitors and gets paged?
+2. `L2 escalation`: who investigates and fixes?
+3. `L3 ownership`: who decides rollback, communication, and commercial response?
+
+If those answers are weak, recommend a lower-risk entry path and a tighter scope.
+
+## Safer framing choices
+
+Use these phrases more often:
+
+- AI teammate
+- augment the team
+- accelerate repetitive work
+- human stays in control
+- start with lower-risk workflows
+
+Use these phrases carefully:
+
+- autonomous
+- fully automated
+- replaces analysts or engineers
+- set it and forget it
+
+## Positioning heuristic
+
+| Capability reality | Best default framing |
+| --- | --- |
+| AI suggests and user decides every time | Copilot |
+| AI performs meaningful work but user still governs the outcome | Teammate |
+| AI acts with meaningful autonomy and the audience is autonomy-friendly | Agent |
+
+## Demo pattern
+
+Do not show only the perfect path. A stronger enterprise demo usually shows:
+
+1. the current manual problem and cost
+2. the AI attempt on realistic data
+3. uncertainty, failure, or a needed correction
+4. the human review and control point
+5. the quantified improvement
+
+This builds more trust than a polished "everything worked" demo.
+
+## Objection response moves
+
+### "What happens when it breaks?"
+
+Respond with a failure-handling scenario, not an accuracy boast. Walk the buyer through alerts, triage, rollback, and scope control.
+
+### "How do we trust this in production?"
+
+Answer with evidence in this order:
+
+1. transparency: what it does, what data it touches, what controls exist
+2. control: approval points, fallbacks, kill switches, audit trail
+3. performance: baseline comparison, case studies, pilot outcomes
+4. scale: enterprise readiness, operational model, support boundaries
+
+### "Are you replacing our team?"
+
+Reframe to augmentation and capacity. Focus on repetitive work, decision support, and throughput rather than headcount elimination.
+
+## Qualification questions
+
+Ask these when the buyer sounds excited but operationally unready:
+
+- What happens today when a tool or automation causes a production issue?
+- Who would own investigation if this workflow failed at 2 a.m.?
+- Which environments or workflows are safe enough for a phased rollout?
+- What evidence would your operations or risk team need before they approve broader deployment?

package/.jumpstart/skills/gtm-ai-gtm/references/jumpstart-and-pod-alignment.md

@@ -0,0 +1,72 @@
+# Jump Start And Pod Alignment
+
+Use this reference when the user needs guidance on whether to lead with a Jump Start, move directly to the AI Innovation Pod, or recommend a hybrid motion.
+
+## Decision logic
+
+| Situation | Recommended motion | Why |
+| --- | --- | --- |
+| The client has multiple candidate use cases, low clarity, or weak stakeholder alignment | Jump Start | Discovery and prioritization are the highest-value next step |
+| The use case is already validated and the client needs working capability quickly | Pod | A pre-integrated team accelerates architecture, build, and iteration |
+| The AI layer is only one part of a broader application or transformation program | Hybrid | The Pod can lead the AI workstream while adjacent teams own the surrounding scope |
+| The client expects long-term run-state ownership, enterprise platform modernization, and broad app delivery from one small team | Reframe | Position a broader Sogeti solution, not a Pod-only motion |
+
+## Buyer signals
+
+Jump Start signals:
+
+- "We know AI matters but we are not sure where to start."
+- "We have several use cases and need help choosing."
+- "We need an executive-ready roadmap before we ask for funding."
+- "We want to see what is feasible in our environment."
+
+Pod signals:
+
+- "We have a specific use case and need to build fast."
+- "We need architecture plus hands-on implementation."
+- "We want a working MVP or pilot in users' hands in weeks, not quarters."
+- "We need a cohesive team, not a few disconnected specialists."
+
+Hybrid signals:
+
+- "Our platform or app team will stay in place, but we need AI specialists."
+- "We need the Pod to define the AI layer while another team owns app engineering or data engineering."
+- "We want the Pod to establish the scaffold and then hand off industrialization."
+
+## Scope boundaries to state explicitly
+
+Always name what the Pod does not automatically own:
+
+- enterprise platform ownership
+- privileged release approvals
+- long-term run and support
+- broad application engineering outside the AI use case
+- enterprise data platform modernization unless that scope is explicitly included
+
+## Delivery pattern guidance
+
+Recommend one of these patterns explicitly:
+
+1. `Pod-led innovation sprint`: use when the primary risk is discovery, feasibility, or proving value quickly.
+2. `Embedded co-delivery`: use when the client already has adjacent app, data, QA, or operations teams.
+3. `Accelerate and handoff`: use when the Pod should establish architecture, first release scaffolding, and working patterns before transition.
+
+## Suggested recommendation language
+
+### When recommending Jump Start first
+
+Recommend a Jump Start when the main risk is choosing the right use case, aligning stakeholders, and defining a realistic path to value. Position the workshop as the shortest route to a scoped backlog, architecture direction, and decision-ready next step rather than as a generic training event.
+
+### When recommending direct Pod entry
+
+Recommend direct Pod entry when the client has enough clarity to start building and the main need is speed, multidisciplinary execution, and a rapid feedback loop. Position the Pod as a specialized AI innovation layer that can lead the AI workstream, not as a replacement for every adjacent delivery function.
+
+### When recommending a hybrid
+
+Recommend a hybrid motion when the client already has strong delivery muscles in app engineering, data, QA, or operations but lacks specialized AI design and execution capacity. Make the handoffs explicit so the proposal does not hide ownership risk.
+
+## Handoff language
+
+Use language like this when the answer needs to connect Jump Start to Pod work:
+
+"The Jump Start should produce the prioritized use case, target workflow, success metrics, architecture direction, risk register, and recommendation on whether to continue into a Pod-led MVP. If the outputs confirm value and feasibility, the Pod becomes the execution layer that converts the validated concept into a working release path."

package/.jumpstart/skills/gtm-ai-gtm/references/pricing-and-packaging.md

@@ -0,0 +1,41 @@
+# Pricing And Packaging
+
+Use this reference when the user needs pricing guidance, offer packaging, or a commercial story for AI products or Pod-style services.
+
+## Pricing models
+
+| Model | Best fit | Main risk | Guidance |
+| --- | --- | --- | --- |
+| Seat-based | Predictable user-level augmentation | Heavy users may be underpriced | Use when usage variance is modest and value scales with adoption |
+| Usage-based | Variable machine work with clear units | Customers optimize to use less | Use only when the buyer understands the unit and the value per unit is clear |
+| Outcome-based | Outcomes can be measured and attributed cleanly | Vendor absorbs too much risk if outcomes are noisy | Use carefully and avoid when many dependencies sit outside the offer |
+| Hybrid | Usage varies materially but some base capability is fixed | Overcomplex pricing if poorly explained | Often the safest default for AI offers with variable demand |
+
+## Packaging rules of thumb
+
+- Price against customer alternative cost, not model-provider list price.
+- For AI product motions, align variable pricing to a meaningful unit of value, not raw tokens unless the user explicitly needs that level of detail.
+- For Pod motions, frame the offer as subscription access to integrated capability, velocity, and outcome-oriented execution rather than hours.
+- Separate discovery, prototype, productionization, and run-state economics. Do not blur them.
+
+## Jump Start and Pod commercial guardrails
+
+When the ask involves Jump Starts or Pods:
+
+- Treat the Jump Start as a fixed-scope discovery and design motion.
+- Treat the Pod as a flexible capability model whose tier should match maturity, urgency, and depth of execution.
+- State that scaled build, platform ownership, or managed run services may require adjacent teams or follow-on scope.
+
+## Commercial language patterns
+
+Use language like:
+
+- "subscription access to a pre-integrated AI innovation capability"
+- "shared focus on validated assumptions, working outputs, and decision velocity"
+- "the right entry point depends on clarity, urgency, and execution readiness"
+
+Avoid language like:
+
+- "guaranteed business outcome" when the client controls key dependencies
+- "all-in-one replacement" when multiple delivery functions are clearly needed
+- "priced just like model consumption" when the offer includes delivery, governance, or change work

package/.jumpstart/skills/gtm-ai-gtm/templates/client-gtm-brief.md

@@ -0,0 +1,40 @@
+# [Client Or Offer Name]
+
+## Executive Summary
+[2-4 sentences on the buyer situation, the recommended GTM motion, and why it matters now.]
+
+## Buyer Problem And Context
+- Buyer type:
+- Current pain or trigger:
+- Why existing approaches fall short:
+- Urgency or business driver:
+
+## Recommended Positioning
+- Recommended framing:
+- One-sentence value proposition:
+- Supporting proof points:
+- What not to imply:
+
+## Recommended Entry Motion
+- Jump Start, Pod, product, or hybrid:
+- Why this is the right starting point:
+- What should happen next:
+
+## Commercial And Packaging Guidance
+- Pricing or packaging model:
+- Scope boundary:
+- Key assumption:
+
+## Likely Objections And Responses
+| Objection | Recommended response |
+| --- | --- |
+| [Objection] | [Response] |
+
+## Risks, Assumptions, And Dependencies
+- Confirmed facts:
+- Assumptions:
+- Risks:
+- Client responsibilities:
+
+## Recommended Next Step
+[Specific next meeting, workshop, or proposal action.]

package/.jumpstart/skills/gtm-ai-gtm/templates/jumpstart-to-pod-recommendation-matrix.md

@@ -0,0 +1,36 @@
+# Jump Start To Pod Recommendation Matrix
+
+## Opportunity Snapshot
+| Dimension | Notes |
+| --- | --- |
+| Client / account | |
+| Business problem | |
+| AI use case maturity | |
+| Delivery urgency | |
+| Existing team landscape | |
+
+## Recommendation Matrix
+| Decision Factor | Evidence | Implication | Recommendation |
+| --- | --- | --- | --- |
+| Clarity of use case | | | |
+| Technical feasibility confidence | | | |
+| Stakeholder alignment | | | |
+| Need for hands-on build support | | | |
+| Need for adjacent teams | | | |
+| Operational readiness | | | |
+
+## Recommended Motion
+- Recommended entry point:
+- Why:
+- Suggested tier or phase:
+- What this motion should produce in 2-6 weeks:
+
+## Scope Boundaries
+- In scope:
+- Out of scope:
+- Follow-on scope candidates:
+
+## Handoff Or Expansion Path
+- If starting with Jump Start:
+- If moving into Pod:
+- If hybrid with adjacent teams:

package/.jumpstart/skills/gtm-enterprise-account-planning/SKILL.md

@@ -0,0 +1,169 @@
+---
+name: gtm-enterprise-account-planning
+description: Build or repair an enterprise account plan for a Jump Start or AI Innovation Pod opportunity, including account hypothesis, stakeholder map, MEDDICC evidence, personal wins, route recommendation, and mutual action plan. Use this whenever the user is planning a complex AI deal, qualifying a strategic opportunity, checking whether a deal is real, preparing for account strategy reviews, or deciding between Jump Start, Pod, adjacent Sogeti teams, or a pause.
+argument-hint: Provide account context, deal stage, known stakeholders, client asks, and any existing notes, emails, or MAP.
+license: MIT
+metadata:
+  author: Smit Patel (https://linkedin.com/in/smitkpatel)
+  source: https://github.com/beingsmit/technical-product-gtm
+---
+
+# Enterprise Account Planning
+
+## Positioning
+
+Use this skill to turn rough account context into a defensible enterprise account plan that is useful for Jump Start and AI Innovation Pod work, not just generic pipeline commentary.
+
+The core job is to help the team decide whether the account should move into a Jump Start, a Pod tier, a broader Sogeti motion, or a pause, then show what must happen next for the deal to stay real.
+
+## When To Use This
+
+- The team needs an account plan for a strategic or messy enterprise AI opportunity.
+- A deal has multiple stakeholders, a non-trivial buying process, or signs of stalling.
+- The user needs a MEDDICC view tied to actual evidence rather than hopeful assumptions.
+- The team must decide whether the next move is Jump Start, Ignition, Turbo, Overdrive, adjacent-team pursuit, or no-go.
+- The user needs a mutual action plan, deal-health check, exec prep brief, or recovery plan.
+
+## Typical Need Shapes
+
+- "Turn these account notes into an account plan and tell me whether to sell Jump Start or go straight to the Pod."
+- "This deal has been warm for two months. Is it actually moving or are we fooling ourselves?"
+- "Map the stakeholders, their personal wins, and where the political risk sits."
+- "Draft a MAP for the next three weeks and show what the client has to own."
+- "Prepare me for an account review with leadership and make the route recommendation defensible."
+
+## When Not To Use This
+
+- Do not use this as pure company research. Route to `company-research` when the main need is account intelligence gathering.
+- Do not use this as a pricing calculator. Pull in pricing or proposal assets when the core task is commercial modeling.
+- Do not use this to draft a full proposal or SOW. Route to proposal or SOW skills once the opportunity path is qualified.
+- Do not force-fit every AI conversation into an account plan. If the ask is still vague, use intake or discovery-oriented skills first.
+
+## Required Inputs
+
+- Account name, industry, and what the client appears to care about
+- Current stage, recent interactions, and any urgency signal
+- Known stakeholders and their roles
+- Client ask, pain points, success criteria, or budget/timeline signals if known
+- Existing MAP, notes, emails, meeting recap, or qualification artifacts if available
+
+## Working Rules
+
+1. Separate confirmed facts from hypotheses and unknowns.
+2. Treat MAP freshness as a primary health signal. A stale MAP is stronger evidence than verbal enthusiasm.
+3. Do not recommend a direct Pod motion when clarity, sponsorship, or technical readiness are too weak to support it.
+4. Make personal wins and personal risk explicit for major stakeholders.
+5. Be direct about blockers, ownership gaps, and where the pursuit should pause.
+6. Protect delivery teams by naming adjacent-team dependencies, client responsibilities, and out-of-scope assumptions.
+
+## Workflow
+
+1. Clarify the motion.
+Determine whether the account is early qualification, active pursuit, proposal-stage, or recovery-stage.
+
+2. Build the account hypothesis.
+Summarize what the client is really buying, why now, and why Sogeti is plausibly relevant.
+
+3. Map stakeholders and buying reality.
+Identify the economic buyer, champion, blockers, users, and adjacent teams. Add personal wins, personal risk, and influence level.
+
+4. Assess opportunity strength with evidence.
+Use MEDDICC, Jump Start versus Pod route logic, MAP freshness, and delivery-fit signals. Mark weak evidence plainly.
+
+5. Decide the route.
+Recommend one of: Jump Start, Ignition, Turbo, Overdrive, Pod plus adjacent teams, broader Sogeti motion without Pod, or pause/no-go.
+
+6. Produce the right artifact.
+Match the output to the ask: full account plan, simplified pursuit memo, deal-health readout, mutual action plan, or executive prep note.
+
+## Resource Map
+
+- Use [references/jumpstart-account-planning-guide.md](./references/jumpstart-account-planning-guide.md) for the default decision rules, deal-health logic, and route patterns.
+- Use [templates/account-plan-template.md](./templates/account-plan-template.md) when the user wants a full account plan or a structured internal review artifact.
+- Use [templates/mutual-action-plan-template.md](./templates/mutual-action-plan-template.md) when the immediate need is a working MAP or recovery cadence.
+- Use [examples/example-account-plan.md](./examples/example-account-plan.md) as the tone and structure model for a strong output.
+- Use [../../../01-sell/qualification/qualification-scorecard.md](../../../01-sell/qualification/qualification-scorecard.md) when the route recommendation needs a more explicit go or no-go basis.
+- Use [../../../01-sell/qualification/ai-innovation-pod-tier-internal-routing-guide.md](../../../01-sell/qualification/ai-innovation-pod-tier-internal-routing-guide.md) when selecting Ignition, Turbo, or Overdrive.
+- Use [../../../01-sell/engaging-clients-conversation-guide.md](../../../01-sell/engaging-clients-conversation-guide.md) and [../../../02-scope-and-propose/discovery/discovery-questions.md](../../../02-scope-and-propose/discovery/discovery-questions.md) when discovery is too shallow to support confident planning.
+- Use [../../../05-reference/jumpstart-vs-ai-pod.md](../../../05-reference/jumpstart-vs-ai-pod.md) and [../../../05-reference/understanding-the-ai-innovation-pod.md](../../../05-reference/understanding-the-ai-innovation-pod.md) when the output must explain why the route is Jump Start first, direct Pod, or Pod inside a broader program.
+
+## Output Modes
+
+### Full Account Plan
+
+Use the account plan template and include:
+
+- Executive summary
+- What the client is really asking for
+- Account hypothesis and why now
+- Stakeholder map with personal wins and risk
+- MEDDICC status with evidence and gaps
+- Route recommendation and rationale
+- Risks, dependencies, and next actions
+- Mutual action plan
+
+### Simplified Pursuit Memo
+
+Use when the deal is earlier or lower-investment. Include:
+
+- Situation snapshot
+- Confirmed signals and missing evidence
+- Route recommendation
+- Top three risks
+- Next meeting objective and asks
+
+### Deal Health Readout
+
+Use when the concern is whether the deal is moving. Include:
+
+- Health status: green, yellow, or red
+- MAP freshness and ownership analysis
+- Stakeholder momentum or absence
+- Reset, escalate, or pause recommendation
+
+### Executive Prep Brief
+
+Use when someone needs to enter a client or leadership meeting quickly. Include:
+
+- Account snapshot
+- Stakeholders and likely motivations
+- Current route recommendation
+- Questions that must get answered in the meeting
+- Failure modes to avoid
+
+## Quality Bar
+
+- Show the route logic rather than just naming a recommendation.
+- Keep evidence, assumptions, and unknowns visibly separate.
+- Name who owns each next step. A plan with no owner is not a plan.
+- Make the client's work explicit in the MAP. If only our side has actions, the deal is not real yet.
+- Keep Jump Start and Pod positioning realistic. Discovery outputs are not implementation commitments.
+
+## Common Failure Modes
+
+### Mistaking Interest For Progress
+
+Excitement, compliments, and "this looks great" do not count as progress unless stakeholders are doing work and dates are moving.
+
+### Skipping Economic Buyer Validation
+
+Do not let the team confuse champion enthusiasm with budget authority.
+
+### Selling Turbo Into Ambiguity
+
+If the client still needs prioritization, business case support, or architecture confidence, Jump Start or Ignition is usually the more honest route.
+
+### Hiding Delivery Dependencies
+
+If the opportunity clearly needs ACE, DAE or I&D, QET, CIS, security, or another team, say so. Do not hide enterprise delivery work inside a Pod recommendation.
+
+## Related Skills
+
+- `company-research` for account intelligence and external context
+- `qualification-scorecard` for a more formal go or no-go assessment
+- `client-email-writer` when the next step is a seller follow-up email
+- `proposal-narrative` or `sow-proposal-reviewer` once the pursuit is qualified and moves into proposal or SOW drafting
+
+## Regression Evals
+
+Regression prompts live in [evals/evals.json](./evals/evals.json). Keep them realistic and biased toward messy enterprise AI opportunity planning, route decisions, and MAP recovery instead of generic sales theory.

package/.jumpstart/skills/gtm-enterprise-account-planning/evals/evals.json

@@ -0,0 +1,39 @@
+{
+  "skill_name": "gtm-enterprise-account-planning",
+  "evals": [
+    {
+      "id": 0,
+      "prompt": "I need help with an account review for a manufacturing client called ForgePeak. We had two discovery calls about using AI for plant maintenance and technician knowledge search. The VP of Operations is interested, the CIO joined one call, and a plant systems director keeps asking whether their internal data team could just do this themselves. They want something moving this quarter, but they still have at least three candidate use cases and nobody has agreed on success metrics. Budget sounds possible but not locked. Please turn this into an account plan and tell me whether we should sell Jump Start, Ignition, Turbo, or something else.",
+      "expected_output": "A structured account plan that separates facts from hypotheses, maps stakeholders and personal wins, and recommends a realistic route that does not over-accelerate into build without enough clarity.",
+      "files": [],
+      "expectations": [
+        "The output clearly recommends Jump Start and explicitly explains why Turbo is premature or not yet justified.",
+        "The output separates confirmed facts from hypotheses or unknowns rather than blending them together.",
+        "The output includes a stakeholder map or equivalent stakeholder section that names motivations, personal wins, or risks.",
+        "The output includes a mutual action plan with at least one client-owned action."
+      ]
+    },
+    {
+      "id": 1,
+      "prompt": "Tell me if this deal is actually alive and draft the next move. Client is a regional health system exploring an AI contact center copilot. We demoed three weeks ago. Champion said leadership loved it, but our MAP has not been updated since then. The only open items are on our side: revised deck, security FAQ, and sample architecture. We still have not met the economic buyer. Their director of digital experience keeps saying she is trying to get time with the COO. I need a deal-health readout and a recovery-oriented mutual action plan.",
+      "expected_output": "A candid deal-health assessment that treats the stale MAP as a warning signal, explains why the deal is at risk, and produces a MAP with client-owned actions plus a recovery recommendation.",
+      "files": [],
+      "expectations": [
+        "The output labels the deal as red, at risk, or equivalent and ties that judgment to the stale MAP or lack of customer-owned actions.",
+        "The output produces a mutual action plan with client-owned actions and dates.",
+        "The output advises against advancing to a direct Pod build recommendation before buyer validation."
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "Can you prep me for an internal strategy call on a retail account? The client wants enterprise search for store operations and merchant teams, but they are also asking if the AI Innovation Pod could sit inside a larger modernization program they already have with another Sogeti team. Sponsor is the SVP of Digital Operations, procurement is known to be slow, and there is pressure to show a path from a quick workshop to a funded next phase. I need a concise executive prep brief that explains the likely route, stakeholders, risks, and what questions we need answered next.",
+      "expected_output": "A concise exec prep brief that connects Jump Start and Pod options, recognizes adjacent-team dependency, and highlights the key unanswered questions before proposal work.",
+      "files": [],
+      "expectations": [
+        "The output recommends a Jump Start-first route and connects it to a likely follow-on motion.",
+        "The output explicitly explains how the Pod would fit inside the broader modernization program alongside adjacent Sogeti teams or delivery owners.",
+        "The output identifies procurement or buying-path risk and names questions that still need answers."
+      ]
+    }
+  ]
+}

package/.jumpstart/skills/gtm-enterprise-account-planning/examples/example-account-plan.md

@@ -0,0 +1,92 @@
+# Example Account Plan
+
+## Executive Summary
+
+- Account: NorthRiver Mutual
+- Industry: Insurance
+- Current stage: Late discovery / early route decision
+- Recommended route: Jump Start followed by likely Ignition or Turbo
+- Confidence level: Medium
+- Why now: Claims operations leaders are under pressure to reduce manual document handling before the next renewal cycle.
+
+## What The Client Is Really Asking For
+
+- Stated ask: "We want to use AI to speed up claims intake and determine whether an AI Innovation Pod could help us this quarter."
+- Underlying business need: Reduce manual triage, shorten claim handling times, and create a defendable roadmap without overcommitting to production scope too early.
+- Why this matters now: The COO is pushing for operational efficiency targets and the CIO wants a low-risk starting point after a prior vendor overpromised.
+
+## Recommended Motion
+
+- Route: Jump Start
+- Why this route fits: The pain is real and funded, but the client still has multiple candidate workflows, uneven data clarity, and no aligned success metric across claims operations and IT.
+- What evidence supports the route: Engaged VP sponsor, explicit urgency, willingness to workshop, and appetite for architecture guidance before MVP spend.
+- What evidence is still missing: Named economic buyer confirmation, usable baseline metrics, and agreement on which claims sub-process should be the first target.
+
+## Confirmed Facts
+
+- Claims teams manually review unstructured documents from email and portal submissions.
+- The VP of Claims Operations wants faster first-touch triage.
+- The CIO is supportive but cautious because a previous automation pilot failed.
+- The client can provide SMEs and workshop participation within two weeks.
+
+## Hypotheses And Assumptions
+
+- The COO is likely the economic buyer or has direct influence on final funding.
+- Security and compliance review will matter early because PII is involved.
+- If the workshop aligns on one bounded intake workflow, the follow-on could start in Ignition or Turbo depending on data access readiness.
+
+## Unknowns That Block Confident Pursuit
+
+- Whether the claims platform APIs can expose the right data quickly
+- Who owns model-risk and compliance approvals
+- Whether budget is approved only for discovery or also for a post-workshop build phase
+
+## Stakeholder Map
+
+| Stakeholder | Role | Influence | Current Stance | Personal Win | Personal Risk | Evidence Quality |
+| --- | --- | --- | --- | --- | --- | --- |
+| Dana Shah | VP Claims Operations | High | Supporter | Faster cycle time and fewer escalations | Another failed transformation initiative | Confirmed |
+| Luis Romero | CIO | High | Cautious supporter | Show disciplined innovation without governance surprises | Repeating a prior vendor mistake | Confirmed |
+| Megan Holt | Claims Transformation Director | Medium | Champion candidate | Modernize intake and become visible change leader | Team resistance if workflow disruption is too high | Inferred |
+| COO unknown | Likely EB | High | Unknown | Efficiency gains and operating leverage | Funding something not ready for enterprise scrutiny | Missing |
+
+## MEDDICC Status
+
+| Dimension | Current State | Evidence | Gap | Next Validation Step |
+| --- | --- | --- | --- | --- |
+| Metrics | Need baseline on claim triage time and manual touch effort | VP cited "too much manual review" | No quantified target yet | Ask for current SLA and throughput metrics |
+| Economic Buyer | Likely COO with CIO influence | Sponsor references COO pressure | No direct access | Confirm buyer and request intro before any proposal |
+| Decision Criteria | Wants low-risk, governed, business-relevant start | Prior vendor failure raised trust concerns | Security and procurement criteria unclear | Ask for evaluation criteria in workshop prep |
+| Decision Process | Discovery can move fast; follow-on approval likely committee based | CIO and operations both involved | Approval path unconfirmed | Map approval sequence in workshop prep |
+| Identified Pain | Manual claims intake is slow and inconsistent | Multiple leaders raised it | Need sharper workflow boundaries | Use Jump Start to narrow target workflow |
+| Champion | Megan could become champion | She is coordinating SMEs | Internal selling behavior not proven | Test whether she can secure EB and data owners |
+| Competition | Status quo plus internal build bias | CIO asked if internal team could absorb it later | No active vendor named | Ask directly about alternatives and timing |
+
+## Deal Health
+
+- Health status: Yellow
+- MAP freshness: No formal MAP yet; follow-up actions currently sit in email threads.
+- Customer-owned actions completed: Workshop date hold and SME list draft.
+- Momentum signal: Sponsor engagement is real, but the buying path is still underdefined.
+- Recovery risk: Moderate if we jump to a build proposal before the workshop sharpens scope and buyer alignment.
+
+## Delivery Dependencies And Boundaries
+
+- Client responsibilities: Provide workshop participants, current-state workflow owners, and baseline operational metrics.
+- Adjacent Sogeti teams or capabilities needed: Security input and possibly data engineering support if the follow-on moves past workshop into integrated MVP delivery.
+- Out-of-scope assumptions to state early: The Pod is not implicitly taking on long-term run-state, enterprise data remediation, or managed operations.
+
+## Next Actions
+
+| Action | Owner | Due Date | Outcome Sought |
+| --- | --- | --- | --- |
+| Confirm workshop objective and participant list | Sogeti seller | 2026-05-05 | Lock Jump Start framing |
+| Share current claims intake workflow and pain points | Client transformation lead | 2026-05-07 | Improve workshop prep |
+| Confirm economic buyer and budget path | Client sponsor | 2026-05-08 | Remove route ambiguity |
+| Draft post-workshop success criteria options | Sogeti architect | 2026-05-09 | Prepare follow-on decision path |
+
+## Meeting Objective
+
+- Next meeting purpose: Confirm that a Jump Start is the right discovery motion and secure the stakeholders needed for a productive session.
+- Questions that must be answered: Who is the economic buyer? What metrics matter most? Which claims intake slice should be first? What governance review is unavoidable?
+- What a good outcome looks like: Workshop approved, sponsor-backed participants named, and a clear post-workshop decision path defined.