원클릭으로
원클릭으로
| name | customer-call-summary |
| description | Customer Call Transcript Processing |
This skill defines how to summarize customer call transcripts for product management insights.
For the expected level of detail, see the example: examples/acme-01-27-26.md
Every customer call summary should include these sections in order:
A detailed overview that orients the reader and captures the key takeaways. Structure:
Quotes: Always weave relevant verbatim quotes directly into the executive summary paragraphs. Quotes bring the exec summary to life - this is the most-read section. Use italicized quotes inline within paragraphs (e.g., "We are digging it." - Derek), not just in insight tables.
Opening paragraph: Status updates and any quick wins/progress since last meeting
Second paragraph: "This call focused on X areas: (1) [topic], and (2) [topic]." - orient the reader on what's covered
Topic sections: For each major topic discussed, add a bold header and detailed paragraph:
**[Topic Name]** (e.g., "Templates for Batch Projects")How [Customer] is Using [Specific Feature/Workflow]: Scope this heading to the specific features or workflows discussed on this call - not a comprehensive overview of all product usage. Example: "How Acme is Using Templates & Generation Deflection" not "How Acme is Using Forge Today." Only reflect what was discussed in the current meeting.
Opportunity Areas: Paragraph or numbered list describing opportunities identified. Tie back to their workflows.
[Product Strategy/Hypothesis] Validation (include when applicable): When a call provides evidence that validates or invalidates a product strategy or hypothesis, add a dedicated section with customer quotes as evidence. Example: "Forge's Upcoming Roadmap Validates User Expansion Strategy" with quotes showing customer enthusiasm and unprompted action (e.g., assigning internal owners before the feature ships). Also add a corresponding insight topic in the Insights/Learnings section with the detailed evidence and quotes.
Key Product Gaps: Bullet list of gaps with specific descriptions. Actively identify implied feature gaps - things the customer is working around, doing manually, or switching to another tool for. Don't just capture features they explicitly request; listen for pain points that imply a missing capability (e.g., "Derek manually exports generated code and re-imports it into their CI pipeline" implies Forge needs direct CI/CD integration).
**Key Product Gaps**
- **[Gap 1]:** [Specific description with context]
- **[Gap 2]:** [Specific description with context]
Organize insights by topic. Each topic section includes:
Topic heading (H3): Group related insights together
### [Topic Name]
Summary: 1-2 sentence summary of what we learned in this topic area
Table format: Use tables with detailed descriptions and quotes on separate lines:
| Insight | Details |
|---------|---------|
| **[Insight headline]** | [Detailed description with specific examples from the call]<br><br>*"[Verbatim quote]" - [Speaker]* |
Level of detail: Include enough context that someone who wasn't on the call understands:
Organize feature requests by area. Each area section includes:
Area heading (H3): Group related features together
### [Area Name] (e.g., "Data Export & Sharing", "Filtering & Search")
Summary: Description of this feature area and the underlying need
Blockers (if applicable):
**Blocker:** [Description of what's blocking progress and any dependencies]
Table format:
| Feature | Details |
|---------|---------|
| **[Feature name]** | [Detailed description]<br><br>*"[Verbatim quote]" - [Speaker]* |
Organize action items by category:
## Next Steps
### [Category] (e.g., "Onboarding", "Template Configuration")
- [Action item] - [Owner]
- [Action item] - [Owner]
### [Next Category]
- [Action item] - [Owner]
Draft a follow-up email to send to the customer contact:
## Follow-up Email
**To:** [Customer contact]
**Subject:** [Meeting Topic] Recap + Action Items
Hi [Name],
Thanks for the great discussion today! Here's a quick recap:
**What we covered:**
- [Key topic 1]
- [Key topic 2]
- [Key topic 3]
**Action items for you:**
- [ ] [Item 1]
- [ ] [Item 2]
**From our side:**
- [Item 1]
- [Item 2]
Let me know if I missed anything!
Best,
Hannah
Draft a ready-to-post Slack message summarizing the call for internal stakeholders.
Format:
Content guidelines:
Example:
Great bi-weekly sync with Acme today! Full recap here.
Project Templates
Shared templates are off to a strong start - 91 projects created from templates
since launch. Derek gave a shoutout to the team: "We are digging it. It's off
to a great start and it's something that we've been looking forward to having
for so long." Acme flagged several issues, and we broke them down in sprint
planning into five template fast follows assigned to Sam and Jordan this week:
1. Fix template versioning when a template is updated after projects were
already created from it (currently orphans the old projects)
2. Update template metadata display - currently shows "generated by Forge"
which is misleading for hand-customized templates
3. Add a "failed generations" tab so teams can see which template configs
are producing low-quality output and why
4. Add project detail link-outs and environment indicators (dev/staging/prod,
Forge Teams vs. Forge Pro) to generated project cards
5. Add a "view deployment" button on generated projects so Acme can check
deploy status without leaving Forge
Derek also noted they're already seeing early positive signals even before
the CI/CD integration is deployed: "There's been a noticeable decrease in the
time from idea to working prototype. And a slight increase in the number of
projects that actually make it to production. So I think Forge is sort of
working. It's just not producing the volume that we need."
Based on our initial data, we're seeing a healthy 40% template-to-deploy
conversion rate, which we think is the floor. Biggest bottleneck to delivering
greater value is template coverage across their tech stack, which reinforces
the React/Vue/Svelte template library and CI/CD integration as P0.
CI/CD integration is still WIP with Acme's setup - once deployed, we expect
a material increase in production deploys since a significant portion of their
projects require automated testing before launch. We also discussed adding
templates for all tiers (including Forge Teams) as an additional lever, which
has been successful with other customers. Derek wants to discuss this further
next meeting in coordination with their internal tooling standardization efforts.
Access Controls, Team Workspaces, and Usage Analytics
Access Controls, Team Workspaces, and Usage Analytics will be a major value unlock for Acme.
Derek's reaction to the access permissions preview was immediate and
enthusiastic - he didn't just want manager access, he wants a structured weekly
review process built around Forge. He's already assigned Priya and Tom
to develop an internal rollout plan before the feature even ships. This validates
our hypothesis that Access Controls and Team Workspaces will expand Forge's user base within
accounts and shift it from an individual prototyping tool to a team-wide dev platform.
"You had me at hello, Hannah. You had me at hello. So, yes, we definitely want
to look at this so that managers we can think about. Not just access, Hannah. What
would really be helpful would be like if you guys created some sort of process
where our engineering leads had to sign in once a week and review their team's
projects and click complete and then Priya gets a notification that they
completed their review." - Derek
Deployment Visibility Within Forge
Priya also flagged the need to surface deployment status within Forge so they
don't have to go to the AWS console to check if a project is already live before
spinning up a new environment - "There is a high chance that if it's a project
deployed through Forge Teams, it's already running on our infrastructure. So we're
not spinning up duplicate instances." We'll solve this by bringing the Deployment
Dashboard into Forge (long-standing ask across multiple Forge customers).
Linear issues to come for all items raised above.
Action items are tracked at the file level (top of the summary file), not per-meeting.
At the top of each customer's summary file, maintain these tables:
## Open Action Items
### Forge Labs
| Action Item | Owner | From Meeting |
|-------------|-------|--------------|
### [CustomerName]
| Action Item | Owner | From Meeting |
|-------------|-------|--------------|
## Completed Action Items
### Forge Labs
| Action Item | Owner | From Meeting | Completed |
|-------------|-------|--------------|-----------|
### [CustomerName]
| Action Item | Owner | From Meeting | Completed |
|-------------|-------|--------------|-----------|
<br><br> before the quote in table cellsThe summary should be detailed enough that someone who wasn't on the call understands the full picture:
See the example for the expected level of detail: examples/acme-01-27-26.md
Before finalizing the summary, verify:
<br><br>)feature-requests/feature-requests.md