Intercom captions: in-app video tours, Help Articles, and ADA compliance for SaaS customer-success teams

Intercom Articles and the ADA Title III obligation for public Help Centers

Intercom Articles is the Help Center product within the Intercom platform. SaaS companies use it to publish a customer-facing knowledge base: step-by-step how-to articles, product feature walkthroughs, onboarding guides, troubleshooting references, release-note summaries, and video tutorials that demonstrate product workflows in motion. The Help Center is publicly accessible — typically at help.company.com or company.intercom.help — and accessible to any visitor, including prospective customers, existing customers with hearing disabilities, and visitors using screen readers or other assistive technology.

Video in Intercom Articles: no native hosting, all embeds

A critical and frequently misunderstood fact about Intercom Articles: Intercom Articles does not have a native video upload or caption generation feature. Authors insert video into articles by pasting a URL from an external video platform — YouTube, Vimeo, or Loom. Intercom renders an iframe embed of the external player. The caption track that appears in that embedded player is the caption track on the external platform. This means:

• If your Intercom Articles article embeds a YouTube video, the caption source is YouTube. You manage captions in YouTube Studio by uploading a corrected SRT.
• If your article embeds a Vimeo video, the caption source is Vimeo. You manage captions in the Vimeo video settings by uploading an SRT or VTT. See our Vimeo captions reference for the upload workflow.
• If your article embeds a Loom recording, the caption source is Loom. You manage captions in Loom by uploading a corrected VTT to replace Loom's auto-transcript (Business/Enterprise tier). See our Loom captions reference.
• If your article embeds a Wistia video, the caption source is Wistia. See our Wistia captions reference for the SRT upload path.

There is no "Intercom Articles caption upload" because Intercom does not host the video. The compliance path for Help Center video runs through the originating video platform's caption management workflow, not through Intercom itself.

ADA Title III: why Help Center video is in scope

ADA Title III (42 U.S.C. § 12181 et seq.) prohibits discrimination against people with disabilities by "places of public accommodation." US federal courts — building on the Robles v. Domino's Pizza Ninth Circuit ruling and subsequent district court decisions in the First, Second, and Seventh Circuits — have consistently held that commercial websites accessible to the general public qualify as places of public accommodation. The DOJ's 2022 Title III web-accessibility guidance confirmed this reading: commercial web content must meet WCAG 2.1 AA or a comparable accessibility standard.

An Intercom Articles Help Center at help.company.com is commercial web content providing product information and support services to the general public, including people with hearing disabilities. Embedded video that lacks accurate captions denies visitors with hearing disabilities equal access to the information the video conveys — the definition of a Title III violation. The relevant WCAG success criterion is SC 1.2.2 (Captions, Prerecorded): all prerecorded audio content in synchronised media shall have captions that "accurately convey" the spoken content. Auto-generated captions from YouTube, Vimeo, or Loom that mangle the SaaS product names, feature names, and workflow terminology the video was made to teach do not "accurately convey" the content under SC 1.2.2.

California Unruh Act: $4,000 per-incident exposure for SaaS companies with California users

For SaaS companies with California customers — which, for any company above a few dozen customers, is virtually all of them — the California Unruh Civil Rights Act (California Civil Code § 51) applies in parallel with federal Title III. The Unruh Act prohibits discrimination in business establishments based on disability, including physical and digital inaccessibility. Unlike federal Title III, the Unruh Act provides for statutory damages of $4,000 per incident of discrimination. A single Help Center video without captions, viewed by a California visitor with a hearing disability who is denied the information the video contains, is a potential $4,000 Unruh Act incident. California plaintiffs' counsel — several firms in San Francisco, Los Angeles, and San Diego have active web-accessibility practices — have brought Unruh Act cases against SaaS companies with inaccessible Help Center video.

The per-incident structure of Unruh Act liability means that a Help Center with multiple uncaptioned videos, viewed by multiple California users over time, represents compounding per-incident exposure. SaaS companies that treat Help Center video captioning as a lower-priority item than application accessibility often reclassify it after seeing the per-incident mathematics. The remediation path — captioning the embedded video at the source platform (YouTube/Vimeo/Loom/Wistia) — is straightforward; the compliance question is whether it has been done.

New York Human Rights Law and New Jersey LAD

The New York Human Rights Law (N.Y. Exec. Law § 296) and the New York City Human Rights Law (N.Y.C. Admin. Code § 8-107) extend "place of public accommodation" protections to commercial websites accessible to New York residents and New York City residents, respectively. New Jersey's Law Against Discrimination (N.J.S.A. § 10:5-1 et seq.) covers public accommodations in New Jersey. A national SaaS company's Intercom Articles Help Center accessible to New York and New Jersey visitors is within the scope of these state laws. Unlike the Unruh Act's flat per-incident damages, NY HRL and NYCHRL damages are measured by actual harm plus compensatory damages and civil penalties; NYCHRL awards attorney fees without a prevailing-party requirement, making it an attractive venue for plaintiffs' counsel.

DOJ web-accessibility enforcement and Title III settlements

The DOJ under both the Biden and (certain components of the) Trump administrations has settled Title III web-accessibility cases against companies across multiple industries. DOJ settlements typically require: (1) adoption of WCAG 2.1 AA as the accessibility standard for all web content, (2) captioning of all video content to WCAG 2.1 AA accuracy, (3) an annual accessibility audit of the website, (4) a publicly posted accessibility statement with a mechanism for users to report accessibility barriers, and (5) a designated accessibility coordinator. SaaS companies whose Help Centers have received DOJ complaint referrals have been required to retroactively caption all Help Center video as part of their settlement obligations.

Help Center video and customer success metrics

Beyond legal compliance, uncaptioned Help Center video undercuts the support-deflection goal that Intercom Articles exists to serve. Customers with hearing disabilities who cannot access an uncaptioned product walkthrough video will submit a support ticket rather than self-serving through the Help Center — directly increasing ticket volume. A Help Center optimised for WCAG 2.1 AA accessibility is also a Help Center that works for the broadest possible customer population, maximising self-service deflection. Accessible Help Center video and high deflection rates are the same goal, not competing ones.

Intercom Product Tours — video elements and public-demo captioning obligations

Intercom Product Tours is the guided in-app walkthrough product: a sequence of tooltip-and-highlight steps that guide a user through a product feature, onboarding flow, or upsell experience. Product Tours can include short embedded video clips — a 30-60-second screen-recording or explainer video embedded within a tour step to show rather than describe a feature. The question of whether those video elements require captions depends on whether the tour runs in a public-accommodation context:

Product demos on publicly accessible pages

Many SaaS companies deploy Intercom Product Tours on their public marketing site — on an interactive demo page accessible to any visitor, or as a signup-completion tour on a page accessible to all trial users including those who signed up without identity verification. When a Product Tour with embedded video runs on a publicly accessible page, the video-in-tour is public-accommodation content under the same Title III analysis as Help Center video. The fact that the video is presented within a tour step rather than in a standalone Help Center article does not change the accessibility obligation: the video conveys information the product tour was designed to communicate, and a visitor with a hearing disability who cannot access that information is denied equal access.

Product Tours in authenticated, post-signup contexts

Product Tours that run only within an authenticated product session — where the user has completed a full signup and verified identity — present a narrower public-accommodation analysis. The "publicly accessible" element of Title III's public-accommodation reading focuses on whether the general public (including prospective customers without existing relationships with the company) can access the content. An authenticated product tour is available only to signed-up users, not to the general public. However, the employer accommodation analysis (ADA Title I) still applies for any users who are employees of the SaaS company itself and use the product, and Section 1557 (for healthcare companies using Intercom for patient-facing product tours) applies if the product is used in a healthcare-delivery context.

Outbound messaging with video content

Intercom's Outbound messaging features — in-app messages, email campaigns, push notifications, and Intercom Series (multi-step automated sequences) — can include embedded video. An outbound in-app message with a video walkthrough delivered to a user's in-app feed is typically in an authenticated context (post-login), reducing the public-accommodation analysis, but it remains content that hearing-impaired users cannot access if uncaptioned. Best practice, and the posture that satisfies employer-accommodation and product-accessibility commitments, is to caption video content in Outbound messages and Series the same as any other product video.

Internal Intercom team training — L&D content types and employer accommodation obligations

Intercom is the operational hub for customer success, onboarding, support, and product-led growth teams at SaaS companies. Each team type produces its own category of internal training video that teaches colleagues how to use Intercom effectively. This internal training content is subject to employer accommodation obligations for hearing-impaired employees under ADA Title I, California FEHA, New York HRL, and New Jersey LAD.

Types of internal Intercom training video

• New Intercom user onboarding. The most common type: screen-recorded walkthroughs that show new CS agents, onboarding specialists, or support teammates how the company's Intercom instance is configured. These cover the Inbox views, conversation routing rules, team assignment logic, macros and canned responses, the Intercom Articles knowledge base structure, and how the company's Fin AI bot is built. Typically recorded in Loom or Camtasia as a screen capture of the company's live Intercom instance.
• Fin AI bot-building training. Intercom Fin AI (the AI support agent, distinct from Fin AI Copilot) is configured by CS operations teams who build Fin workflows, define Fin's knowledge sources (Articles, custom answers, snippets), set handover rules (when Fin escalates to a human teammate), and monitor Fin's resolution metrics. Training videos for CS ops teams on how to build, configure, and iterate on Fin involve dense Intercom-specific vocabulary that generic ASR cannot handle.
• Intercom Workflows automation setup. Intercom Workflows is the visual automation builder for routing conversations, triggering outbound messages based on user behaviour, qualifying leads, and managing bot flows. Training video for the Workflows product is dense with Intercom-specific action and trigger names, conditional logic terminology, and integration vocabulary (Intercom x Salesforce, Intercom x HubSpot, Intercom x Stripe, Intercom x Jira).
• Proactive Support training. Intercom Proactive Support is the feature set for sending outbound messages triggered by user behaviour — in-app messages that fire when a user visits a specific page, Intercom Series that onboard trial users through a sequence of contextual messages, Intercom Surveys triggered at product milestones. Training video for Proactive Support covers audience segmentation (Intercom Segments, Intercom Tags), A/B testing configurations, message performance metrics, and the interaction between Proactive Support and the Fin AI routing.
• Reporting and analytics walkthroughs. Intercom's reporting suite — Inbox reports, Teammate reports, Proactive Support reports, Fin AI resolution metrics — is complex and requires training for CS managers who use these dashboards for team performance and capacity planning. Reporting training videos reference Intercom metrics vocabulary (CSAT scores, First Response Time, Resolution Rate, Fin Containment Rate) and the company's internal performance targets.
• Intercom x CRM integration training. For SaaS companies with a Salesforce or HubSpot integration, the Intercom x Salesforce or Intercom x HubSpot sync is a source of frequent training — how Intercom conversation data maps to Salesforce objects, how Intercom contact records sync with HubSpot, how sales reps access Intercom conversation history within their CRM. This content references both Intercom vocabulary and Salesforce/HubSpot vocabulary simultaneously.

Employer accommodation requirements for hearing-impaired CS team members

Customer success, onboarding, and support teams at SaaS companies include employees with hearing disabilities. ADA Title I (42 U.S.C. § 12112, applying to employers with 15 or more employees) requires employers to provide reasonable accommodation to employees with disabilities. Accessible training — training that a hearing-impaired employee can access with captions that accurately convey the spoken content — is a core reasonable accommodation obligation. California FEHA (Cal. Gov. Code § 12900 et seq., applying to employers with 5 or more employees) has a lower threshold and a broader definition of disability than federal Title I. New York Human Rights Law (N.Y. Exec. Law § 296, applying to employers with 4 or more employees) and New Jersey LAD (all employers) are similarly broad.

A SaaS company that onboards a hearing-impaired CS agent using Loom-recorded Intercom training videos with Loom's auto-generated captions — which will mangle every Intercom product name, every workflow term, and every mention of the company's product vocabulary — may not be providing a reasonable accommodation. The reasonable accommodation obligation requires that the training actually convey the information it purports to convey. A caption track that substitutes phonetic guesses for the specific product names and workflow terms that define the CS agent's job is not "reasonably accurate" by any defensible standard.

Section 1557 for healthcare companies using Intercom

SaaS companies in the healthcare and telehealth sectors frequently use Intercom as their patient-facing communications platform — Intercom Messenger embedded in the patient portal, Intercom Articles as the patient-facing health information library, Intercom Outbound for care-follow-up messages. For these companies, Section 1557 of the Affordable Care Act (42 U.S.C. § 18116) — which prohibits discrimination on the basis of disability in federally-funded health programs and activities — applies both to the patient-facing Intercom content and to the training of the clinical staff who use Intercom. Any covered entity or recipient of federal financial assistance must provide effective communication for people with disabilities, which includes accessible captioning of video content in both the patient-facing Help Center and the internal staff training library. Section 1557 was strengthened under the 2024 HHS rule (89 Fed. Reg. 37,522) that explicitly required accessible video content in patient-facing digital services.

The Intercom vocabulary failure mode — why generic ASR cannot caption Intercom training

Intercom has one of the largest and most distinctive proprietary vocabularies of any SaaS platform in the customer-communications space. The platform has expanded through internal product development and acquisitions over more than a decade, accumulating a product suite with dozens of named components, a workflow vocabulary with dozens of named constructs, and integration partnerships with their own compound-name conventions. Each of these is a systematic failure point for generic ASR that has been trained on general English corpora that include none of these proper nouns.

Intercom product suite names

The following are the named products and features in the Intercom suite that appear in Intercom training video and that generic ASR consistently fails to transcribe correctly:

• Intercom Messenger. The chat widget embedded on company websites and in-app. "Messenger" is a high-frequency generic word that ASR usually renders correctly, but compound uses — "the Intercom Messenger widget," "Messenger's home screen," "customising the Messenger" — can break when the speaker's cadence abbreviates "Intercom Messenger" to just "Messenger" in a way that loses the product context.
• Intercom Articles. Usually transcribed correctly when spoken as a clear two-word phrase. Breaks when narrators say "Articles" rapidly in a list of product names, or when they use the abbreviation "Articles manager" (which ASR sometimes renders as "article manager" losing the capitalised product name).
• Intercom Inbox. Usually fine, but "Inbox views" as a UI construct (the named view categories within Intercom Inbox) is a different surface — "the Assigned to you view," "the Unassigned queue," "the Mentions tab" — where ASR interprets the noun phrases as generic rather than named UI elements.
• Intercom Outbound. This is a significant failure point. The word "Outbound" in "Intercom Outbound" is spoken with variable stress. Some narrators say "outbound" with a British or Australian English pronunciation that ASR maps to "out bound" as two words. The distinction matters for documentation accuracy in training that references the product name precisely.
• Intercom Series. "Series" as a product name (the multi-step automated message sequence builder) is easily confused with the generic noun. "In a Series" or "create a Series" reads correctly; "the Series builder" or "this Series has three steps" requires the capitalised proper-noun reading that generic ASR does not enforce.
• Intercom Surveys. Usually fine when the product is named explicitly. The compound "an in-app Survey" or "send a Survey to users who…" loses capitalisation in generic ASR output, which matters for training documents where Survey is a named product feature distinct from a generic survey.
• Intercom Product Tours. "Product Tours" is a two-word compound that ASR usually handles, but "Tours" alone — "configure the Tour steps," "the Tour is live," "segment the Tour audience" — is read as the generic noun.
• Intercom Switch. This is one of the highest-failure-rate product names in the suite. "Intercom Switch" is the phone-to-messaging channel-switch feature. In audio, "Switch" sounds identical to a Cisco networking device, a Nintendo console, or the generic verb. Generic ASR in context will often transcribe "the Intercom Switch feature" as "the intercom switch feature" (lower-case) or, worse, as "the intercom's switch feature" — a subtly different meaning implying a switch belonging to the intercom hardware device, not the Intercom software product.
• Intercom SMS. Generally fine. "SMS" is a well-known acronym. "Intercom SMS" as a product name is usually transcribed correctly.
• Intercom Fin. This is the single highest-severity vocabulary failure in Intercom training video. "Fin" — as in "Intercom Fin," "Fin AI," "the Fin AI Agent," "Fin AI Copilot" — is a three-letter word with two dangerous homophone-neighbours: "fin" (the fish anatomical feature, the financial abbreviation) and "Finn" (a common proper name). Generic ASR will transcribe "Fin" inconsistently: sometimes correctly as "Fin," sometimes as "Finn" (treating the speaker's short terminal-consonant as the common English name), sometimes as "fin" (lower-case, losing the product name capitalisation). In a transcript of an Intercom Fin AI training video, "configure the Fin AI Agent" might appear as "configure the Finn AI agent" or "configure the fin AI agent" — both of which are wrong and both of which will confuse a CS agent reading the caption track while watching the video. The Intercom Fin AI Agent / Fin AI Copilot distinction — the Agent is the customer-facing autonomous resolver, the Copilot is the in-Inbox AI assistant for human teammates — is also a failure point: "the Fin AI Copilot" may be transcribed as "the fin AI co-pilot" with a hyphen and lower case, erasing the product name distinction.
• Intercom Proactive Support. "Proactive Support" is a two-word product name within the Intercom suite. As a spoken phrase, "proactive support" is a common English collocation that ASR will treat as a generic description rather than a product name, losing the capitalisation and the product-specific meaning. Training narrators who say "configure Proactive Support" or "the Proactive Support feature set" will see "configure proactive support" in the auto-transcript — correct phonetically but incorrect as a product reference.
• Intercom Workflows. The visual automation builder product. "Workflows" as a product name is distinguished from the generic use of "workflows" (as in "our support workflows") only by capitalisation and context. Generic ASR treats both as the same word; the product-name reading requires a glossary entry that forces the product context to the capitalised form when the speaker is clearly discussing the Intercom builder UI.
• Intercom Segments and Intercom Tags. Both are product names within the Intercom data model for user categorisation. Both are common English nouns that ASR transcribes correctly at the phoneme level but incorrectly at the capitalisation level, losing the distinction between "a segment" (generic) and "a Segment" (a named audience group in Intercom).
• Intercom Custom Bots and Intercom Resolution Bot. "Custom Bots" is the configurable chatbot flow builder; "Resolution Bot" (the pre-Fin AI automation bot) is a named product still referenced in legacy training. "Bot" as a word is usually transcribed correctly, but "Resolution Bot" is a two-word compound that can split — "resolution" transcribed as "the resolution bot" (article + noun) vs. "Resolution Bot" (product name). CS teams that trained on Resolution Bot before Fin's launch still have Resolution Bot training video in circulation, and the transcript of that content must accurately preserve the product name to avoid confusing agents who were trained on one system and are transitioning to the other.
• Intercom Canvas Kit. The Messenger-embedded application framework (Canvas Kit) is a developer-facing product. Its most dangerous homophone collision is with Canvas LMS — the learning management system. An engineering team training video that discusses "the Intercom Canvas Kit" can be transcribed as "the Intercom Canvas kit" (product name intact but lower-cased) or, in recordings that include both Canvas Kit references and any upstream mention of the company's LMS, as "the Intercom Canvas LMS integration" — a completely incorrect product conflation.

Intercom workflow and conversation-management terminology

Beyond the product names, Intercom has a distinctive operational vocabulary that appears throughout CS team training video:

• Conversations (not "tickets"). Intercom uses "Conversations" — capitalised in the UI — as the term for customer interactions. Many SaaS support teams cross-train on Zendesk (which uses "Tickets") and Intercom (which uses "Conversations"), and training videos for cross-trained teams explicitly explain this distinction. When a narrator says "unlike Zendesk tickets, Intercom Conversations are structured differently," ASR produces "unlike Zendesk tickets, intercom conversations are structured differently" — losing both capitalisation signals. A hearing-impaired agent relying on captions may not register the product-name distinction that the narrator is making.
• Teammate. Intercom's term for a user-agent of the Intercom account (as opposed to "user" which means a customer). "Teammate" is occasionally transcribed as "team mate" (two words), losing the Intercom-specific terminology. Correct transcription of "Teammate" vs. "team member" vs. "agent" is important in training that explains Intercom's data model and permission structure.
• Inbox views. The named views in Intercom Inbox — "All," "Assigned to you," "Assigned to your teams," "Unassigned," "Mentions," "Spam," "Closed" — are proper UI element names. Training video that navigates the Inbox and refers to these views by name relies on those names appearing correctly in the caption track, so that a hearing-impaired agent can match what they read to what they see on-screen.
• CSAT (Customer Satisfaction), NPS (Net Promoter Score), SLA (Service Level Agreement). These acronyms appear in every Intercom reporting training and are generally transcribed correctly (all three are in generic ASR training data), but the Intercom-specific context — "Intercom's CSAT survey triggers at conversation close," "the SLA timer in the Intercom Inbox" — requires that the surrounding Intercom vocabulary also be correct for the acronym to read in context.
• Workload Management. Intercom's round-robin and load-balancing team routing feature. "Workload Management" as a product feature is a common English phrase that ASR renders as generic text; training that explains "how Workload Management routes conversations to available teammates" loses the product-name capitalisation.
• Snooze. The conversation snooze feature (defer a conversation reply to a specified future time). "Snooze" as a word is usually transcribed correctly, but its use as a specific Intercom product action — "snooze the conversation for 2 hours," "the snooze function in the Inbox" — requires context consistency that generic ASR treats as a generic verb/noun.
• Assignment Rules and Routing Rules. The automation constructs for routing conversations to specific teams or teammates based on conversation attributes. Both are two-word product constructs that ASR renders as generic noun phrases.
• Conversation Data Attributes. Custom data fields attached to Intercom conversations. The three-word compound is usually transcribed correctly but loses the capitalised product-concept status that distinguishes it from generic "conversation data" in a training context.

Intercom integration vocabulary

Intercom's integration ecosystem — hundreds of integrations documented in Intercom's App Store — produces compound vocabulary that appears in CS and ops training video:

• Intercom x Salesforce, Intercom x HubSpot, Intercom x Stripe, Intercom x Jira. The "x" (cross/times) connector in these integration names is spoken differently by different narrators — "Intercom cross Salesforce," "Intercom and Salesforce," "the Intercom Salesforce integration" — and ASR may transcribe the "x" as the letter "x," as "cross," as "times," or drop it depending on pronunciation. Training video that explains the Intercom x Salesforce data sync needs this compound name to appear consistently.
• Intercom REST API, Intercom JavaScript API, Intercom iOS SDK, Intercom Android SDK. For engineering-team Intercom training (deploying the Messenger, building Canvas Kit apps, using Webhooks), these SDK and API names carry capitalisation and casing conventions. "JavaScript API" spoken quickly is usually transcribed correctly. "iOS SDK" is a known ASR failure point: "iOS" is spoken as "eye-oh-ess" by most narrators, which ASR may transcribe as "I.O.S." (with periods), "iOS" (correct), or "IOS" (incorrect all-caps). "Android SDK" is usually correct. "REST API" may appear as "rest API" (lower-case "rest") or "REST API" (correct acronym), depending on the ASR system's handling of context.
• Intercom Webhooks. "Webhooks" (one word, capital W) is the standard industry spelling; ASR frequently outputs "web hooks" (two words) or "web-hooks" (hyphenated), losing the standard one-word proper-noun form.

The company product vocabulary layer on top of the Intercom vocabulary layer

Every SaaS company's Intercom training video carries a second proper-noun layer on top of the Intercom platform vocabulary: the company's own product names, feature names, pricing tier names, and internal workflow labels. The CS team at a SaaS product that has features named "Autopilot," "DataSync," "FlowBuilder," and "CommandCenter" — and whose Intercom training video explains how those features relate to Intercom's product workflows — needs both the Intercom vocabulary and the company product vocabulary to be in the glossary. Generic ASR fails on both layers simultaneously. The compound failure rate on Intercom CS training video at SaaS companies is among the highest we measure across any content category — because the two vocabulary layers reinforce each other's errors when a narrator uses a company feature name and an Intercom workflow term in the same sentence.

Caption workflow for Intercom-adjacent video platforms

Because Intercom Articles does not host video natively, the captioning workflow always runs through the platform that does host the video. Customer success teams at SaaS companies use a characteristic mix of video platforms for both customer-facing Help Center content and internal training:

YouTube-embedded Help Center and tutorial video

YouTube is the most common platform for Intercom Articles video, particularly for longer product walkthroughs and tutorial series that companies also publish publicly on their YouTube channel. The workflow for captioning YouTube-embedded Intercom Articles video:

1. Generate a corrected SRT or VTT caption file for the video using a glossary-biased captioning workflow that includes the company's product vocabulary and the Intercom platform vocabulary as the project glossary.
2. In YouTube Studio, open the video, click Subtitles, and upload the corrected SRT as a new subtitle track. This replaces or supplements YouTube's auto-generated track.
3. The corrected caption track propagates immediately to all embeds of that YouTube video — including the Intercom Articles iframe embed on the Help Center page.

YouTube auto-generated captions for a SaaS product walkthrough video will fail on every product name, every feature name, and every Intercom workflow term that appears in the narration. The corrected SRT upload is the compliance path.

Vimeo-embedded Help Center and training video

Vimeo is used by SaaS customer-success teams that want more player control than YouTube provides — custom player branding, privacy controls, no YouTube recommended-video sidebar. Vimeo supports SRT and VTT caption upload in the video settings panel. See our Vimeo captions for training videos reference for the full upload workflow. The corrected caption track displays in the Vimeo player when embedded in Intercom Articles.

Loom-embedded async video for CS teams

Loom is the async-video tool of choice for SaaS customer-success teams — the platform that CS reps use to record quick product walkthroughs for customers, that onboarding teams use to record personalised onboarding guides, and that CS ops teams use to record internal Intercom training. Loom URLs can be directly embedded in Intercom Articles (Intercom renders a Loom embed when a Loom URL is inserted into an article). On Loom Business and Enterprise plans, a corrected VTT can be uploaded to replace Loom's auto-generated caption track. The corrected track then displays in the Loom player when embedded in Intercom Articles. See our Loom captions reference for the VTT upload workflow and the privacy posture on customer-name handling in CS-use Loom recordings.

Wistia for customer-education video

SaaS companies with more sophisticated customer-education programmes often use Wistia for Help Center and knowledge base video — Wistia provides analytics, lead capture, and branded player experiences that YouTube and Vimeo do not. Wistia accepts SRT caption uploads via the Customize panel in each video's settings. Wistia also integrates directly with Intercom (the Wistia x Intercom integration can track video view events as Intercom user attributes, enabling Proactive Support messages triggered by video-watching behaviour). The Wistia-Intercom integration makes Wistia a natural choice for SaaS companies that want to close the loop between customer education video and Intercom-triggered follow-up. See our Wistia captions reference for the upload workflow. The SRT Wistia accepts is the same glossary-biased output that GlossCap produces upstream.

Microsoft Stream for M365-tenant companies

SaaS companies in the Microsoft 365 ecosystem — and particularly large enterprise SaaS customers or SaaS companies that themselves run on M365 internally — often record Teams meetings and then share the recording as an Intercom training video link. Microsoft Stream (the video hosting component of M365) hosts these recordings and can serve them as embeds. Stream supports caption upload via the SRT format (accessible through the video's caption settings in the Stream admin panel). See our Microsoft Stream captions reference for the M365 tenant caption workflow.

The caption platform routing decision

For a CS team that uses a mix of YouTube (public product tutorials), Loom (async internal training and CS-rep walkthroughs), and Wistia (customer academy), the captioning workflow is the same at the upstream stage — produce a corrected SRT or VTT using glossary-biased captioning — and diverges at the upload step based on the destination platform. A unified glossary (company product names + Intercom platform vocabulary) built once and applied consistently across all three destination platforms is the operational pattern that scales across a CS team's full video library.

See GlossCap pricing

Compliance framework for Intercom video content

Intercom video content sits within a layered compliance framework that varies based on whether the content is customer-facing or internal, and whether the company operates in specific regulatory sectors:

ADA Title III — public-facing Help Center and Product Tour video

ADA Title III (42 U.S.C. § 12181 et seq.) is the primary federal accessibility law for public-facing Intercom Articles Help Center video. The obligation: commercially accessible video must have captions that accurately convey the audio content to WCAG 2.1 AA SC 1.2.2 standards. Scope: any US SaaS company whose Intercom Articles Help Center is accessible to the public, which is the default configuration for all Intercom Articles Help Centers that have not been explicitly restricted to authenticated users. Enforcement: private civil actions (the plaintiff can be any individual with a disability denied accessible access), DOJ enforcement actions and settlements, and state-level parallel actions under Unruh, NY HRL, NYCHRL, NJ LAD.

ADA Title I — internal Intercom team training

ADA Title I (42 U.S.C. § 12112) is the employment-discrimination counterpart to Title III. Scope: employers with 15 or more employees. The obligation relevant to captioning: providing accessible training materials is a component of reasonable accommodation for employees with disabilities. An employer that provides Intercom onboarding training exclusively as video-with-auto-captions that fail on Intercom product vocabulary may not be meeting its Title I reasonable accommodation obligation for hearing-impaired CS employees. State equivalents — California FEHA (5+ employees), New York HRL (4+ employees), New Jersey LAD (all employers) — apply at lower employer-size thresholds and are frequently more aggressive in their reasonable-accommodation standards.

Section 1557 — healthcare companies using Intercom for patient communication

Section 1557 of the Affordable Care Act applies to covered entities and recipients of federal financial assistance in health programs and activities. Telehealth companies, patient-communication platforms, digital health SaaS companies, and healthcare providers that use Intercom to communicate with patients — patient-facing Intercom Articles Help Centers, Intercom Messenger for patient messaging, Intercom Outbound for care-navigation messages — must ensure those communications are accessible to patients with disabilities, including hearing-impaired patients. The 2024 HHS Section 1557 rule (89 Fed. Reg. 37,522) explicitly addresses digital accessibility of health program communications, requiring accessible video captioning in patient-facing digital content. For healthcare-adjacent SaaS companies, this creates a Section 1557 obligation that runs parallel to (and is sometimes more demanding than) the Title III public-accommodation analysis.

California Unruh Act — $4,000 per-incident for California users

California Civil Code § 51 (Unruh Civil Rights Act) provides for $4,000 statutory damages per incident of discrimination in business establishments. Courts and plaintiffs' firms in California have applied this to inaccessible commercial website video. For SaaS companies with California customers — effectively all SaaS companies above a minimal customer count — each uncaptioned Help Center video viewed by a California visitor with a hearing disability represents a potential $4,000 Unruh Act incident. The per-incident structure means that a Help Center with ten uncaptioned videos and one California user with a hearing disability who views each video represents $40,000 in potential Unruh exposure, exclusive of attorney fees.

European Accessibility Act — EU SaaS companies' Intercom Help Centers

Intercom is widely used by European SaaS companies whose Help Centers serve EU customers. The European Accessibility Act (EAA) has been enforceable since June 28, 2025 under Directive 2019/882. The EAA requires accessibility for consumer-facing digital services in scope — including digital services provided by commercial SaaS companies to consumers. The technical standard under the EAA is EN 301 549, which references WCAG 2.1 AA as the operative web content accessibility standard. An EU SaaS company's Intercom Articles Help Center accessible to EU consumers is in scope for EAA compliance; video embedded in those Help Center articles must meet EN 301 549 / WCAG 2.1 AA accessibility standards, including accurate captions under SC 1.2.2.

The EAA's small-enterprise exemption (Article 4(5)) exempts microenterprises (fewer than 10 employees and annual turnover or balance sheet under €2 million) from certain EAA obligations for service providers, but does not exempt companies from national implementations of the EAA that member states chose to apply more broadly. SaaS companies at the 50-500-employee scale that GlossCap serves are above the microenterprise threshold in all EU member states and are not eligible for the exemption. See our EAA captions requirements reference for the full enforcement timeline and member-state implementation status.

State digital accessibility laws beyond California

Several US states have enacted or are implementing state-level digital accessibility laws that apply to commercial websites beyond the federal ADA Title III framework. Colorado's HB 21-1110 (state digital accessibility law, applying to state agencies and contractors), New York's state-level digital accessibility initiatives, and proposed legislation in other states are expanding the compliance landscape. Our state digital accessibility laws reference covers the current state-law landscape and the SaaS employer exposure by state.

How GlossCap handles Intercom training video

The glossary-biased captioning workflow for Intercom video — whether the video is a customer-facing Help Center tutorial, an internal Fin AI training walkthrough, or an Intercom Workflows automation setup screen-recording — follows the same upstream process:

1. Build the Intercom vocabulary layer. GlossCap pulls the company's product vocabulary from Notion, Confluence, or Google Docs (the standard knowledge sources for SaaS L&D teams). The Intercom platform vocabulary — the named product suite, the workflow terms, the integration names — is added as a standard module for any project that includes Intercom training content. The full list of Intercom product names, workflow terms, and integration vocabulary catalogued in the section above is included in the Intercom vocabulary module.
2. Run the audio through glossary-biased Whisper decoding. The glossary boosts the probability weights for the correct surface forms of Intercom product names and company product vocabulary during the Whisper decoding pass. "Fin" decodes correctly as a product name rather than a lower-case noun. "Workflows" decodes as the product name rather than the generic plural. "Canvas Kit" decodes as the Intercom developer framework rather than the Canvas LMS.
3. Reviewer pass with amber-highlight UI. Every glossary-applied term is highlighted with source-line provenance in the GlossCap review UI. A CS ops lead or L&D team member verifies the glossary applications — particularly the ambiguous terms like "Fin" (is this the Intercom AI agent or a fin-related word?) and "Series" (is this the Intercom automation product or a generic sequence?). Corrections feed the workspace glossary for future recordings.
4. Export SRT and VTT. The reviewed caption file exports as both SRT (for YouTube, Vimeo, Loom, Wistia, and LMS upload) and VTT (for Loom VTT replacement and web-player display). The export complies with WCAG 2.1 AA SC 1.2.2 accuracy requirements.
5. Upload to the source video platform. The SRT or VTT uploads to YouTube Studio, Vimeo's caption settings, Loom's transcript replacement, or Wistia's caption panel. The corrected track propagates to all embeds of that video, including any Intercom Articles embed.

For SaaS CS teams with a substantial back catalogue of uncaptioned Intercom training video, the batch-processing workflow — enumerate the team's Loom workspace, YouTube channel, or Vimeo account; process all videos in a single batch with the unified Intercom + company vocabulary glossary; upload all corrected tracks — is the practical retrofit path. The Loom Workspace API, YouTube Data API, and Vimeo Data API all support programmatic caption upload for bulk operations.

FAQ — Intercom captions

Further reading

• WCAG 2.1 AA captions: what SC 1.2.2 requires for prerecorded video
• WCAG captions for prerecorded content: the accuracy standard explained
• State digital accessibility laws: California, New York, Colorado — the SaaS employer exposure
• European Accessibility Act captions requirements: what SaaS companies need to know
• Loom captions: async-video for SaaS CS teams with customer-name privacy posture
• Vimeo captions for training videos: SRT/VTT upload workflow for SMB video hosting
• Wistia captions: B2B SaaS video hosting, Channels, and customer-academy captioning
• Microsoft Stream captions: M365-tenant caption workflow for Teams recordings
• Zendesk captions: Help Center video, agent training, and ADA compliance
• Freshdesk captions: Help Center video and support-team training captioning
• Sales enablement video captions: product names, competitor names, and the searchable-deck workflow
• The hidden half-FTE in your L&D budget: caption correction costs