Chat collection and analysis
In February 2025, I implemented advisor-chat download and AI analysis, using a Yingdao application with multiple collection subflows.
Case 02 / Conversation intelligence
I connected conversation collection, AI analysis and business-facing delivery. The work began with chat records and later extended to voice retrieval, transcription, cloud synchronization and frontend reports.
Start with the problem ↓Before anyone can use an insight, the right conversations must be collected, made readable, analyzed and delivered somewhere people can access.
The delivered work was a chain of integrations, with different milestones for text and voice.
In February 2025, I implemented advisor-chat download and AI analysis, using a Yingdao application with multiple collection subflows.
I developed the next version in March 2025. Related reminder delivery changed when the enterprise messaging channel imposed restrictions.
In January 2026, I connected voice retrieval and download to transcription, then passed the resulting text into AI assessment.
Returned voice-analysis results were written to a synchronized cloud folder and displayed in the frontend. This was part of delivery, not an optional last step.
The diagram separates the human task, the text-analysis milestone and the later voice extension. It is a reconstruction, not a live connection.
I connected collection and analysis, then adapted result delivery as the messaging channel changed.
Download advisor conversations through RPA subflows.
Pass collected chat content into AI analysis.
Turn returned analysis into a business-facing result.
Distribute results through the available channel.
Voice adds a transcription stage; cloud synchronization and a frontend complete the delivery chain.
Find and download the recordings.
Convert speech into text.
Analyze the transcript.
Write results to the cloud folder.
Present the result in the frontend.
Text and voice were delivered at different stages. Delivery channels remained subject to account and platform constraints.
Animated process illustration · no live business data
Each extra component should remove a real handoff or make the result usable. It also creates a dependency to maintain.
A good prompt does not retrieve the right records or route the result. Collection and delivery were necessary to make analysis repeatable in daily work.
The delivered voice workflow reused text as the analysis input. The trade-off is an additional transcription stage whose errors can affect downstream interpretation.
When messaging restrictions changed, I adjusted reminder distribution rather than treating model output as the end of the system. Later account/channel constraints still limited operation.
Cloud-file synchronization and a frontend made voice-analysis results accessible. This does not imply real-time streaming, identical architecture across versions or uninterrupted availability.
I connected collection, processing and report delivery, then maintained the integrations as operating constraints changed.
Repeatable collection and processing replaced separate handoffs; voice-analysis output became available through a frontend report.
No matched before/after timing study or validated analysis-accuracy score is available. I do not borrow timing figures from the scheduling case.
Public diagrams contain no customer conversations, recordings, identities or internal endpoints. They explain my contribution and the delivery sequence, not production telemetry.
See how repetitive administration evolved into APIs and a shared data foundation.