Telemetry & analytics for real-time and AI-powered calling
Turning raw client and service signals into the numbers engineers actually act on.
- Role
- Design lead and implementer
- Organisation
- Microsoft
- signal to decision
- KQL → BI
The problem
Real-time calling produces an enormous volume of telemetry from two very different places: clients running on every platform, and the services behind them. Those sources disagree — different clocks, different sampling, different definitions of the same event.
Without a shared, trusted definition of reliability, latency and service health, teams end up arguing about whose dashboard is right instead of fixing the underlying product.
What I did
Led the design and implementation of telemetry, analytics and reporting solutions covering real-time communication and AI-powered calling scenarios.
Built Kusto-based telemetry pipelines that normalise and join client and service telemetry into consistent, queryable datasets.
Delivered Power BI dashboards on top of those pipelines so reliability, latency and service-health metrics are reviewable by engineers and leadership without writing a query.
Treated metric definitions as an interface: agreed semantics first, then implementation, so downstream consumers can rely on the numbers not shifting underneath them.
Outcome
Engineering teams can measure reliability, latency and service health for real-time and AI-powered calling scenarios directly, rather than inferring them.
Telemetry became a first-class input to operational decision-making — deployment validation, alerting analysis and engineering health review.
Investigations into telemetry discrepancies now resolve to a root cause across sources instead of stopping at 'the dashboards disagree'.