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
From scattered conversations to usable analysis.
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 ↓01 / Human workflow
The problem was more than analysis.
Before anyone can use an insight, the right conversations must be collected, made readable, analyzed and delivered somewhere people can access.
- Collect chat records or voice recordings instead of repeatedly locating them by hand.
- For voice, download the audio and turn it into text before text-based analysis.
- Run the analysis and organize the returned output.
- Make results available to the relevant colleagues—not just leave them in a model response.
02 / Implementation
The parts I connected.
The delivered work was a chain of integrations, with different milestones for text and voice.
Version 2.0 and distribution
I developed the next version in March 2025. Related reminder delivery changed when the enterprise messaging channel imposed restrictions.
Voice processing
In January 2026, I connected voice retrieval and download to transcription, then passed the resulting text into AI assessment.
Output people can use
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.
03 / Data flow
Follow the data, then the result.
The diagram separates the human task, the text-analysis milestone and the later voice extension. It is a reconstruction, not a live connection.
Open full-size diagram ↗Scroll sideways on a small screen. Text explanation follows.
04 / Technical decisions
The choices behind the workflow.
Each extra component should remove a real handoff or make the result usable. It also creates a dependency to maintain.
Automate collection, not just prompting
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.
Transcribe before text analysis
The delivered voice workflow reused text as the analysis input. The trade-off is an additional transcription stage whose errors can affect downstream interpretation.
Adapt delivery channels
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.
Reports over raw responses
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.
05 / Outcome
Results and scope.
I connected collection, processing and report delivery, then maintained the integrations as operating constraints changed.
What changed for the user
Repeatable collection and processing replaced separate handoffs; voice-analysis output became available through a frontend report.
What remains unmeasured
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.