presales-technical-consulting

name	presales-technical-consulting
description	Plan and execute enterprise technical discovery, outcome-led demos, POCs, solution architectures, competitive responses, and evaluation closeout. Use when a sales opportunity needs technical qualification or evidence for a customer decision.

Presales Technical Consulting

Use this skill to turn an enterprise opportunity into a bounded, evidence-led technical evaluation. Do not invent customer facts, product capabilities, benchmarks, integrations, certifications, or competitor claims.

Intake

Capture the minimum context before recommending an activity:

• customer, industry, business objective, current workflow, and quantified impact;
• stakeholders, technical evaluators, economic buyer, approver, and blockers;
• current architecture, data, security, integration, deployment, and operational constraints;
• decision criteria, alternatives, timeline, budget status, and required evidence;
• known facts, customer statements, assumptions, and open questions as separate fields.

If a missing answer changes scope or feasibility, ask for it. Otherwise state the assumption and continue.

Discovery

Structure discovery around outcomes rather than a feature checklist:

1. Establish the current state and the cost, risk, or delay it creates.
2. Define the desired future state and measurable outcome.
3. Identify who experiences the problem and who decides whether it is solved.
4. Translate needs into decision criteria and ranked success metrics.
5. Map each criterion to evidence: documentation, demo, reference architecture, benchmark, or POC result.

Produce a discovery matrix with: objective, current state, impact, requirement, priority, metric, evidence, owner, status, and open question.

Outcome-led demo

Build demos in this order:

1. Restate the customer's scenario and target result.
2. Show the shortest end-to-end path that proves the result.
3. Explain only the implementation details needed by the audience.
4. Tie each scene to a decision criterion and observable evidence.
5. Close with confirmed fit, gaps, questions, and the next decision.

For every scene specify audience, setup, sample data, talk track, action, expected output, business relevance, fallback, duration, and owner. Never run a generic feature tour.

POC plan

A POC must contain:

• one-sentence hypothesis and business context;
• in-scope and explicitly out-of-scope items;
• baseline, metric, target, measurement method, and evidence owner;
• data, environment, access, security, integration, and staffing prerequisites;
• milestones, daily/weekly checkpoints, issue path, and change control;
• success, partial success, failure, stop, and exit criteria;
• final readout date and decision gate.

Keep the POC as small as possible while still testing the risky assumptions. A POC is not production implementation.

Solution architecture

Describe:

• actors, systems, trust boundaries, and ownership;
• request, event, and data flows;
• APIs, protocols, schemas, rate limits, retries, and failure handling;
• identity, authorization, secrets, encryption, retention, residency, and audit;
• deployment topology, capacity assumptions, observability, support, and recovery;
• confirmed capabilities, conditional fit, gaps, workarounds, dependencies, and open decisions.

Trace every architecture choice to a customer requirement or operational constraint.

Competitive and objection response

Use FIA for each claim:

• Fact: a sourced, date-stamped, verifiable statement;
• Impact: why it matters for this customer's criterion or risk;
• Act: a fair question, demonstration, or validation step.

For objections: acknowledge, clarify the underlying concern, classify it as fact/risk/misunderstanding/commercial condition, answer with evidence, and agree on a validation action. Do not disparage competitors or present stale claims as current.

Evaluation notes and closeout

Maintain one decision record throughout the evaluation:

• executive outcome and current recommendation;
• decision criteria with weight, status, evidence, and source;
• requirement-to-capability traceability;
• activity log and customer feedback;
• risks, gaps, mitigations, owners, and due dates;
• commercial or legal dependencies clearly separated from technical fit;
• next decision, participants, date, and required inputs.

Use web-search for current external evidence. Use docx, xlsx, pptx, or pdf only after reading the corresponding skill from <available_skills>, and verify the generated artifact before delivery.