Oral Clinic Digital Solution PPT

Purpose

Generate a complete, ready-to-use 口腔机构数智化解决方案 PPT for e看牙 sales communication. The deck must be suitable for oral clinic owners, managers, operations leads, or business owners. Keep all visible slides client-facing, evidence-grounded, and free of internal suggestions or source citations.

Do not install this skill automatically, and do not modify any knowledge base unless the user separately asks for that.

Load References

Load only what is needed:

• references/rules.md: product scope, source priority, evidence boundaries, conversion-rate emphasis, slide rules, and case rules.
• references/workflow.md: end-to-end process from intake through PPT output and QA.
• references/templates.md: sales intake, confirmation questions, evidence log, diagnosis, solution mapping, slide outline, and deck spec templates.
• references/prompt-modules.md: reusable prompt modules for systems that support chained prompts.
• references/pptx-generation.md: instructions for creating a real .pptx with the bundled script.
• references/acceptance-tests.md: tests and acceptance criteria.
• scripts/build_oral_solution_ppt.py: creates a PPTX and companion .evidence.md from a JSON deck spec.
• assets/sample_deck_spec.json: runnable example for the PPTX builder.

Non-Negotiable Rules

1. Use only these products unless the user provides explicit approved evidence for another scope: e看牙智能版, 智能工牌, e看牙机器人.
2. For any operating metric, especially conversion metrics, use 《门诊经营指标口径统一标准（v1.0）》 as the P0 source. If no P0 definition is available, do not invent formulas, thresholds, benchmark ranges, or explanations.
3. Treat conversion rate as a major operating-value theme for 智能工牌. Assess 初诊转化率, 复诊转化率, 到诊转化率, 咨询转化率, 成交转化率, and follow-up process indicators when evidence exists.
4. Ask for missing high-impact confirmation points first, but do not block PPT output. If the user wants to continue, produce the PPT from verified known facts only.
5. Always prioritize PPT delivery after intake. Missing information, recommendations, source evidence, and internal requirements must not appear on visible PPT pages.
6. Keep source notes outside visible slides. Use speaker notes when available, or the companion evidence log.
7. Do not place 待补充, 资料不足, 建议确认, 内部建议, 销售要求, source filenames, or evidence citations on client-facing pages.
8. Customer cases must not become a large standalone section by default. Put at most one approved case in the bottom row of the relevant scenario page, using one concise sentence.
9. Never fabricate product functions, cases, customer data, customer quotes, metric values, thresholds, growth percentages, or causal attribution.

Workflow

1. Intake and confirmation
• Parse customer background, goals, known data, pain points, current systems, sales stage, target audience, and case permissions.
• Ask a short confirmation list for missing high-impact points.
• If the user answers, incorporate the answers. If not, continue with a conservative deck based on verified information.

1. Evidence retrieval
• Retrieve P0 metric definitions first whenever metrics or operating judgments appear.
• Retrieve P1 product capabilities and boundaries for the three allowed products.
• Retrieve P2 implementation paths and management actions.
• Retrieve P3 approved customer cases only when they match a scenario.
• Build an internal evidence log before writing slide content.

1. Diagnosis
• Use: known fact -> metric or phenomenon judgment -> business impact -> controllable problem -> source.
• Highlight conversion funnel leakage where supported, especially for 智能工牌 scenarios.
• Avoid broad unsupported claims about management ability or operating maturity.

1. Solution mapping
• Map each verified problem to product capability, action mechanism, implementation action, process metric, management checkpoint, and source.
• State product value as a mechanism and management path, not as a guaranteed result.
• Keep product capability separate from staff execution and management accountability.

1. PPT outline
• Create an internal outline with slide number, conclusion-style title, purpose, visible points, case use, and source note.
• Use 12-18 slides for normal cases. Expand to 18-30 slides when verified problems or content density require it.

1. PPT generation
• Produce a complete deck or deck-ready content first.
• For actual .pptx, convert the outline into a JSON spec and run scripts/build_oral_solution_ppt.py.
• Use this structure: cover, communication logic, current state and goals, diagnosis, conversion-rate diagnosis if relevant, overall blueprint, scenario solution pages, implementation plan, process metrics and management review, value summary, closing.
• Put concise case notes only inside relevant scenario slides.
• Put evidence sources in notes or evidence log, never on visible pages.

1. QA
• Check unsupported claims, product scope, metric口径, conversion-rate coverage, case evidence, visible internal caveats, page density, terminology consistency, and data integrity.
• If evidence is missing, narrow or remove the visible claim instead of exposing uncertainty on the slide.

Output

Deliver:

• A complete client-ready PPTX or slide-by-slide deck content.
• A companion evidence log or speaker notes that records where each page's information came from.
• A short internal handoff note only when useful, listing missing inputs, conservative assumptions, and remaining risks.

Do not include internal suggestions, requirements, or evidence-source text on visible PPT pages.