Having evaluated the new 'action items' feature across several client deployments, I have to say the initial implementation feels undercooked. The promise of automated task extraction from meeting transcripts is compelling, especially for compliance-driven environments where audit trails are critical. However, the current logic for parsing and assigning verbs seems brittle, which significantly impacts its utility in real-world DevOps and project management workflows.
The core issue is that the feature often generates incomplete or ambiguous tasks. It's excellent at identifying *subjects* and *objects* (e.g., "John," "the deployment script," "Q3 report"), but it frequently misses or misidentifies the **key action verb**. This transforms a potential time-saver into a manual cleanup exercise.
**Specific pain points observed:**
* **Verb Dropping:** A transcript line like "We need to migrate the database schema by Friday" might yield an action item simply titled "Database schema." The critical verbs "migrate" and the deadline context are lost.
* **Ambiguous Assignment:** "Mike will review the security findings and update the runbook." This could generate two separate items: "Mike: security findings" and "Mike: runbook." The specific actions—"review" and "update"—are absent, leaving the assignee to guess what's actually required.
* **Lack of Configurable Parsing Rules:** In infrastructure work, verbs are highly specific and carry distinct meanings (e.g., `apply`, `destroy`, `approve`, `rollback`). The inability to train or add custom verb patterns limits its use for technical teams.
For this to move from a novelty to a robust feature, Fireflies needs to treat action item generation as an NLP problem requiring domain-aware parsing. A simple noun-chunk extractor isn't sufficient. The system should infer intent from a broader context window.
**Suggested improvements for the engineering team:**
1. **Verb Priority Dictionary:** Allow workspace admins to define a prioritized list of action verbs relevant to their domain (e.g., `deploy`, `fix`, `contact`, `approve`, `document`). The parser should weight these higher.
2. **Contextual Awareness:** The action item should inherit the deadline and project context from the surrounding sentences in the transcript, not just the single sentence where the subject appears.
3. **Output Template Configuration:** Enable the action item title and description to be formatted via a template. For example:
`{verb} {object} by {deadline}`
This would turn the raw output into "Migrate database schema by Friday."
Until these are addressed, I cannot recommend relying on this feature for automated ticket creation in systems like Jira or ServiceNow. The manual correction overhead currently negates the automation benefit. For now, it serves best as a high-level meeting summary aid, not an operational workflow integration.
- Mike
Mike
That's a really clear breakdown of the problem. I'm curious, do you see this as more of an NLP engine limitation or a training data issue? Like, would feeding it examples of correctly parsed action items from past meetings help it learn the right verbs?
Exactly. The verb dropping is a killer for ROI. I saw it generate "Post-mortem report" from "Sarah needs to draft the post-mortem report." No verb, no owner. You can't assign that.
It feels like the training data was all formal project docs, not messy meeting language where verbs get implied.
Trust the trial period.