Rebecca Stone’s call for ISPs to treat home connectivity as business-critical is directionally right, but the numbers behind her August 5 Broadband Breakfast essay do not yet support the capacity-planning conclusions attached to them. The Plume chief customer and marketing officer presents a useful view of activity across Plume-managed homes; it is not a published measurement study that can establish how U.S. and European work cultures differ, or prescribe region-wide network profiles.
The distinction matters for Windows users and IT administrators because Teams and Zoom performance at home is rarely solved by buying a faster advertised speed tier. Microsoft’s own Teams guidance puts the emphasis on usable upstream capacity, latency, jitter, packet loss, Wi-Fi design and VPN routing. Those are conditions that a household’s monthly application consumption cannot reveal on its own.
Stone’s essay says Plume analyzed anonymized aggregate data from millions of U.S. and European subscriber households between January 2025 and May 2026. It reports that 38.78% of active U.S. households and 20.34% of European households conduct a business video call on a given workday, with Europe showing longer Teams usage and 2.14 times the monthly Teams bandwidth per household. Those are interesting signals from a large operational footprint. But Plume has not disclosed enough of the underlying method to turn them into a general rule for operators—or a diagnosis for a work-from-home user whose Teams calls freeze at 10:30 a.m.
The central issue is denominator drift. Stone writes about “business video-conferencing households” and says penetration reflects daily averages across “active households,” while framing the findings as evidence about remote work. Those are not interchangeable populations.
A household can generate Teams or Zoom traffic for many reasons that do not identify a person as a remote worker: a student’s class, an evening appointment, a family member joining an employer call from the office on a phone, a telehealth consultation, or a video meeting held outside normal working hours. Conversely, remote workers can spend a day in Outlook, SharePoint, Remote Desktop, GitHub, a virtual desktop session, an enterprise VPN or a line-of-business web app without launching a video meeting.
The U.S. Bureau of Labor Statistics reported that 22.6% of people who were working teleworked or worked from home for pay in March 2026. Its June 2026 table put the comparable figure at 21.7% among people at work. Neither government measure conflicts with Plume’s 38.78% household figure because one is a worker-level employment survey and the other is a daily application-traffic measure across homes. But that difference is precisely why Plume’s number cannot be read as a remote-work rate, or as evidence that nearly two in five U.S. homes have a resident working remotely on every weekday.
Stanford’s Global Survey of Working Arrangements reaches a more restrained conclusion: working from home stabilized after its post-pandemic decline, with college-educated employees in English-speaking countries averaging roughly 1.5 to two work-from-home days each week and European workers somewhat below that range. That supports the broad premise that home networks remain work infrastructure. It does not independently verify the Plume figures, their claimed four-percentage-point year-on-year growth, or the proposed U.S.-Europe behavioral split.
Plume’s estate is also not a random sample of either continent. It consists of homes served by operators using Plume’s platform, a commercial base that can differ by country, ISP tier, housing type, device mix, household income and broadband technology. A sample described only as “U.S.” and “Europe” masks enormous differences between, for example, fiber-heavy urban markets, cable networks, DSL holdouts, and homes with fixed wireless access. No country list, operator mix, access-technology split, sample counts, confidence intervals, or weighting method accompanies the essay.
That is not a minor footnote. It means the research may be very valuable for the individual Plume partners represented in the data, while remaining unsuitable as a proxy for all U.S. or European residential broadband customers.
If 2.41 hours is the median duration of a distinct Teams session, it would indeed indicate unusually long calls. If it is median aggregate Teams time per eligible household over a month, it instead represents roughly 4.8 minutes per day across a 30-day month, or about 7.2 minutes per weekday. Those tell radically different stories about workload and provisioning. The text does not say which interpretation is correct, even though it uses the number to infer that Europeans hold “fewer, longer, more substantive sessions.”
The methodology note says only that “session time uses median values.” It does not define a session boundary, identify whether background connectivity is counted, explain whether the figure includes calls, meetings, chat presence, file transfers or screen sharing, or say whether it applies to all active households or only homes classified as Teams users. There is no other outlet reporting the timing or a technical appendix that resolves the ambiguity.
The application-reach statistics need the same treatment. The essay says Zoom reaches 58% of U.S. business-video households and Teams reaches 67%, while the two platforms “together account for approximately 77–78%” of those households. In Europe, the stated figures are 45% for Zoom and 74% for Teams. The individual platform percentages exceed 100% when added in both regions, so the groups plainly overlap—or the measures use different denominators. That is normal in a world where one employee uses Teams internally and Zoom for customer calls, but the article never states the overlap or defines “together account for.”
Without those definitions, readers cannot determine whether the reported difference reflects meeting habits, application classification, local operator composition, device behavior, or a mix of all four.
But a regional median of monthly application traffic does not identify the part of a network that failed. Microsoft says Teams can deliver HD video under 1.5 Mbps in favorable conditions, while group meetings and screen sharing can require more capacity depending on video layout, resolution and frame rate. Zoom similarly publishes requirements ranging from hundreds of kilobits per second for baseline video to several megabits per second for 720p or 1080p calls.
For a home user, a bad meeting is often an upstream quality problem rather than an aggregate-volume problem. It may be bufferbloat during an upload, interference on 2.4 GHz Wi-Fi, a crowded mesh backhaul, an old wireless driver, a VPN that hairpins media through a distant corporate gateway, a flaky cable signal, poor peering, or packet loss beyond the access network. Microsoft’s own Teams troubleshooting and call-quality guidance focuses on packet loss, round-trip time, jitter, Wi-Fi coverage and endpoint performance for that reason.
A six-person Teams meeting with cameras and screen sharing will not necessarily consume bandwidth comparable to a movie stream, despite the comparison in Stone’s piece. A 4K streaming service can consume substantially more downstream throughput. The operational distinction is that adaptive video streaming can buffer ahead, while conversational media cannot conceal delay or burst loss for long. ISPs should plan around busy-hour concurrency, upstream headroom, latency and loss—not simply the monthly byte total attributed to a collaboration app.
Yet ISPs do not need to treat pervasive app-level classification as the prerequisite to improving service. The actionable layer is frequently closer to the subscriber: managed gateway telemetry, Wi-Fi airtime and retransmission data, signal quality, queue delay, upload saturation, DNS and routing diagnostics, and customer-permitted tests. A provider can identify a congested access node or a household whose Wi-Fi channel is saturated without inspecting the purpose of every encrypted flow.
This is especially important for corporate Windows users. Microsoft 365 administrators already have Teams call analytics and quality dashboards that expose loss, jitter, round-trip time, device issues, codec information and media failures at the meeting level. That is far more precise than inferring a bad business call from home-network traffic alone, and it gives the employer and user a clearer path to decide whether the fault lies with the PC, corporate VPN, home Wi-Fi, ISP or Microsoft service path.
Plume’s commercial interest is not hidden: its own recent material describes application intelligence and operator tools intended to give ISPs deep, application-level visibility. That does not invalidate the data. It does mean its recommendation to sell work-from-home optimization is also a recommendation for the category of intelligence platform Plume provides.
But the immediate response should be measurement, not a regional marketing template. ISPs need to segment by access technology, service tier, country, local busy-hour behavior and observed impairment; enterprises need to collect Teams call-quality data before telling staff to upgrade broadband; and Windows users should first test wired Ethernet or 5 GHz/6 GHz Wi-Fi, update wireless drivers, reduce simultaneous uploads and compare behavior with and without a corporate VPN.
Until Plume publishes the definitions behind its “session” and application-reach figures, its U.S.-Europe comparison is best treated as an operational lead for further analysis—not proof that Europe needs one Quality of Experience profile and the United States another.
Stone’s essay says Plume analyzed anonymized aggregate data from millions of U.S. and European subscriber households between January 2025 and May 2026. It reports that 38.78% of active U.S. households and 20.34% of European households conduct a business video call on a given workday, with Europe showing longer Teams usage and 2.14 times the monthly Teams bandwidth per household. Those are interesting signals from a large operational footprint. But Plume has not disclosed enough of the underlying method to turn them into a general rule for operators—or a diagnosis for a work-from-home user whose Teams calls freeze at 10:30 a.m.
Plume’s figures measure managed homes, not the remote workforce
The central issue is denominator drift. Stone writes about “business video-conferencing households” and says penetration reflects daily averages across “active households,” while framing the findings as evidence about remote work. Those are not interchangeable populations.A household can generate Teams or Zoom traffic for many reasons that do not identify a person as a remote worker: a student’s class, an evening appointment, a family member joining an employer call from the office on a phone, a telehealth consultation, or a video meeting held outside normal working hours. Conversely, remote workers can spend a day in Outlook, SharePoint, Remote Desktop, GitHub, a virtual desktop session, an enterprise VPN or a line-of-business web app without launching a video meeting.
The U.S. Bureau of Labor Statistics reported that 22.6% of people who were working teleworked or worked from home for pay in March 2026. Its June 2026 table put the comparable figure at 21.7% among people at work. Neither government measure conflicts with Plume’s 38.78% household figure because one is a worker-level employment survey and the other is a daily application-traffic measure across homes. But that difference is precisely why Plume’s number cannot be read as a remote-work rate, or as evidence that nearly two in five U.S. homes have a resident working remotely on every weekday.
Stanford’s Global Survey of Working Arrangements reaches a more restrained conclusion: working from home stabilized after its post-pandemic decline, with college-educated employees in English-speaking countries averaging roughly 1.5 to two work-from-home days each week and European workers somewhat below that range. That supports the broad premise that home networks remain work infrastructure. It does not independently verify the Plume figures, their claimed four-percentage-point year-on-year growth, or the proposed U.S.-Europe behavioral split.
Plume’s estate is also not a random sample of either continent. It consists of homes served by operators using Plume’s platform, a commercial base that can differ by country, ISP tier, housing type, device mix, household income and broadband technology. A sample described only as “U.S.” and “Europe” masks enormous differences between, for example, fiber-heavy urban markets, cable networks, DSL holdouts, and homes with fixed wireless access. No country list, operator mix, access-technology split, sample counts, confidence intervals, or weighting method accompanies the essay.
That is not a minor footnote. It means the research may be very valuable for the individual Plume partners represented in the data, while remaining unsuitable as a proxy for all U.S. or European residential broadband customers.
The Teams session statistic is described inconsistently
The most striking figure in the essay is also the least clear. Stone writes that the “median Teams session” in Europe runs 2.41 hours “per household per month,” versus 1.43 hours in the U.S. A session duration and time per household per month are different measurements.If 2.41 hours is the median duration of a distinct Teams session, it would indeed indicate unusually long calls. If it is median aggregate Teams time per eligible household over a month, it instead represents roughly 4.8 minutes per day across a 30-day month, or about 7.2 minutes per weekday. Those tell radically different stories about workload and provisioning. The text does not say which interpretation is correct, even though it uses the number to infer that Europeans hold “fewer, longer, more substantive sessions.”
The methodology note says only that “session time uses median values.” It does not define a session boundary, identify whether background connectivity is counted, explain whether the figure includes calls, meetings, chat presence, file transfers or screen sharing, or say whether it applies to all active households or only homes classified as Teams users. There is no other outlet reporting the timing or a technical appendix that resolves the ambiguity.
The application-reach statistics need the same treatment. The essay says Zoom reaches 58% of U.S. business-video households and Teams reaches 67%, while the two platforms “together account for approximately 77–78%” of those households. In Europe, the stated figures are 45% for Zoom and 74% for Teams. The individual platform percentages exceed 100% when added in both regions, so the groups plainly overlap—or the measures use different denominators. That is normal in a world where one employee uses Teams internally and Zoom for customer calls, but the article never states the overlap or defines “together account for.”
Without those definitions, readers cannot determine whether the reported difference reflects meeting habits, application classification, local operator composition, device behavior, or a mix of all four.
Longer meetings do not automatically mean a new peak-capacity requirement
Plume is on firmer ground when it says real-time work traffic deserves more attention than a residential broadband plan built around downstream streaming. A Teams meeting with screen sharing, cloud synchronization and a busy Wi-Fi network can expose weak upload capacity and local contention fast. The consequences are also more visible to the subscriber than a momentary reduction in streaming resolution.But a regional median of monthly application traffic does not identify the part of a network that failed. Microsoft says Teams can deliver HD video under 1.5 Mbps in favorable conditions, while group meetings and screen sharing can require more capacity depending on video layout, resolution and frame rate. Zoom similarly publishes requirements ranging from hundreds of kilobits per second for baseline video to several megabits per second for 720p or 1080p calls.
For a home user, a bad meeting is often an upstream quality problem rather than an aggregate-volume problem. It may be bufferbloat during an upload, interference on 2.4 GHz Wi-Fi, a crowded mesh backhaul, an old wireless driver, a VPN that hairpins media through a distant corporate gateway, a flaky cable signal, poor peering, or packet loss beyond the access network. Microsoft’s own Teams troubleshooting and call-quality guidance focuses on packet loss, round-trip time, jitter, Wi-Fi coverage and endpoint performance for that reason.
A six-person Teams meeting with cameras and screen sharing will not necessarily consume bandwidth comparable to a movie stream, despite the comparison in Stone’s piece. A 4K streaming service can consume substantially more downstream throughput. The operational distinction is that adaptive video streaming can buffer ahead, while conversational media cannot conceal delay or burst loss for long. ISPs should plan around busy-hour concurrency, upstream headroom, latency and loss—not simply the monthly byte total attributed to a collaboration app.
Application visibility is useful, but it is not the only tool
Stone argues that application-layer visibility is becoming “table stakes” because aggregate throughput cannot distinguish entertainment from a work meeting. For a managed Wi-Fi provider, knowing that a customer experienced poor Teams quality can improve support triage and reduce the ritual of blaming the laptop, router and ISP in sequence.Yet ISPs do not need to treat pervasive app-level classification as the prerequisite to improving service. The actionable layer is frequently closer to the subscriber: managed gateway telemetry, Wi-Fi airtime and retransmission data, signal quality, queue delay, upload saturation, DNS and routing diagnostics, and customer-permitted tests. A provider can identify a congested access node or a household whose Wi-Fi channel is saturated without inspecting the purpose of every encrypted flow.
This is especially important for corporate Windows users. Microsoft 365 administrators already have Teams call analytics and quality dashboards that expose loss, jitter, round-trip time, device issues, codec information and media failures at the meeting level. That is far more precise than inferring a bad business call from home-network traffic alone, and it gives the employer and user a clearer path to decide whether the fault lies with the PC, corporate VPN, home Wi-Fi, ISP or Microsoft service path.
Plume’s commercial interest is not hidden: its own recent material describes application intelligence and operator tools intended to give ISPs deep, application-level visibility. That does not invalidate the data. It does mean its recommendation to sell work-from-home optimization is also a recommendation for the category of intelligence platform Plume provides.
The practical lesson for Windows and network admins
The home network has become more consequential for hybrid work, and providers that still regard residential upload, Wi-Fi reliability and real-time media as afterthoughts will create avoidable support problems. Plume’s data reinforces that broad point, particularly its finding that business collaboration traffic reaches into a large share of its managed-home base during the workday.But the immediate response should be measurement, not a regional marketing template. ISPs need to segment by access technology, service tier, country, local busy-hour behavior and observed impairment; enterprises need to collect Teams call-quality data before telling staff to upgrade broadband; and Windows users should first test wired Ethernet or 5 GHz/6 GHz Wi-Fi, update wireless drivers, reduce simultaneous uploads and compare behavior with and without a corporate VPN.
Until Plume publishes the definitions behind its “session” and application-reach figures, its U.S.-Europe comparison is best treated as an operational lead for further analysis—not proof that Europe needs one Quality of Experience profile and the United States another.
References
- Primary source: Broadband Breakfast
Published: 2026-08-05T15:25:20+00:00
Loading…
broadbandbreakfast.com - Related coverage: minneapolisfed.org
Loading…
www.minneapolisfed.org - Related coverage: census.gov
Loading…
www.census.gov - Related coverage: shrm.org
Loading…
www.shrm.org - Related coverage: siepr.stanford.edu
Loading…
siepr.stanford.edu - Related coverage: zoom.com
Loading…
www.zoom.com - Related coverage: explore.zoom.us
Loading…
explore.zoom.us - Related coverage: britopian.com
Loading…
britopian.com - Related coverage: techradar.com
Loading…
www.techradar.com - Related coverage: time.com
Loading…
time.com - Related coverage: learn.microsoft.com
Loading…
learn.microsoft.com - Related coverage: learn.microsoft.com
Loading…
learn.microsoft.com