As Head of Marketing at Browse AI, I've been experimenting with something that's completely changed how I create content. While everyone's sharing their "game-changing prompts," I've been taking a different approach: feeding our entire support documentation into AI tools.
The results? My AI actually knows what Browse AI does. Like, really knows.
The problem with linking vs. uploading
I used to do what everyone does - paste a link to our support site into ChatGPT and hope for the best. The results were often ‘thin’ and ‘generic’, the content was always left wanting, I also felt like I was spending a lot of time telling the LLM how our product actually worked.
Then I tried something different. Instead of linking, I scraped our entire support site into a database and uploaded it directly.
The difference was immediate. My AI assistant could now explain the depth of our product’s capabilities, could decode our technical documentation into landing pages, and could create internal enablement content at scale.
What this actually looks like in practice
Here's how I'm using this in my day-to-day:
Writing product pages without the back-and-forth
I upload our support database and share a link to one of our high-converting product pages:
Using the support documentation for [NEW FEATURE] and this page structure: [URL],
create product page copy that follows the same template.
Match the:
- Section order and headings
- Tone and style
- Types of examples and benefits
- CTA placement and language
Pull all feature details from the support docs to ensure accuracy.
I get content that matches our proven templates. The output gives me a strong starting place to refine.
Internal enablement that actually helps
I've turned our support docs into the ultimate onboarding tool. New team member joining? Instead of scheduling five product demos, I give them this:
Create a product overview guide for a new [ROLE] joining Browse AI.
Using the support documentation, explain:
- Our 5 core features and what makes them unique
- Common customer use cases for each
- Quick wins they can achieve in week 1
- Where to dive deeper on each feature
Keep it practical - what do they actually need to know to be successful?
Test their knowledge! Create custom quizes for them to complete as they scale from 'beginner' to 'expert' product knowledge relative to their role.
For new feature launches, I create instant enablement:
We're launching [FEATURE]. Create internal enablement materials:
1. 5-minute 'training guide' for the org
2. Sales talk track with objection handling
3. Support team FAQ
4. Success team implementation guide
5. An internal quiz for the entire company to complete
Base everything on the support documentation for accuracy.
Product marketing cheat sheets that teams actually use
My product marketing team loves this one. We create feature cheat sheets that everyone can reference:
Create a one-page cheat sheet for [FEATURE] using support docs:
- What it does (one sentence)
- Who it's for (specific use cases)
- Key benefits (3 max)
- How it works (3-5 steps)
- Common questions and answers
- Competitive advantages
Format for quick scanning during customer calls.
These become the single source of truth during customer conversations.
Building a complete feature positioning library
This is my secret weapon. I scraped both our support docs AND our marketing site, then combined them to create a master positioning document:
For [FEATURE], create a positioning entry that includes:
- Technical capabilities (from support docs)
- Marketing positioning (from website)
- Target audience and use cases
- Key differentiators
- Links to learn more (docs, guides, videos)
Flag any inconsistencies between how we describe it technically vs. marketing-wise.
Now anyone in the company can quickly understand not just what a feature does, but how we talk about it and who it's for. No more "wait, how do we position this again?" moments.
Creating how-to content that's actually helpful
I needed to write a guide on scraping e-commerce sites. Old way: spend an hour testing the product, taking screenshots, writing steps.
New way:
Create a step-by-step guide for scraping product data from e-commerce sites using Browse AI.
Pull the exact steps from the documentation.
Include common issues and solutions.
Add a note about which sites this works best with.
The AI pulls real steps from our docs, not generic fluff. I still review and add screenshots, but the heavy lifting is done.
Catching documentation drift automatically
We built this automation that I'm particularly proud of. When engineering ships a new feature, it:
- Searches our support database
- Identifies potentially affected articles
- Sends a Slack message with what might need updating
It's not foolproof - sometimes it flags things that don't actually need changes. But it catches enough that we've stopped having those embarrassing moments where a customer points out our docs are three features behind.
The setup: Browse AI (to monitor our changelog) + Claude (to analyze the impact) + Make.com (to tie it together).
The competitive intelligence hack
I scraped our main competitors' support sites too. Now when product asks "How does [Competitor] handle pagination?" I can get a real answer based on their actual documentation, not marketing speak.
Compare how Browse AI handles infinite scroll vs [Competitor].
Use only what's stated in the documentation.
Focus on actual workflow differences.
Keeping our messaging consistent across channels
You know how product features can be described differently on your homepage vs. your docs vs. your sales deck? I scraped our entire website and compared it against our support docs to ensure we're telling the same story everywhere.
Compare the website's description of [FEATURE] with the support documentation.
Flag any differences in:
- How the feature is described
- What capabilities are mentioned
- Technical specifications
- Use cases provided
Technical documentation that non-technical teams can actually use
This one's huge for our technical buyers who need to communicate with non-technical stakeholders. I scraped our API docs, webhook guides, and integration documentation. Now when a customer asks "can your API do X?" I don't have to bother our devs:
Using our API and integration documentation, explain:
- Can Browse AI [SPECIFIC TECHNICAL REQUEST]?
- What are the technical requirements?
- What's the implementation effort (easy/medium/complex)?
- Any rate limits or restrictions?
- Code sample or workflow example
Make it technical enough for technical buyers but clear enough for business stakeholders.
Suddenly, I can write blog posts about our webhooks, REST API, or authentication methods without needing a CS degree. The AI translates the technical specs into marketing-friendly language while keeping it accurate.
The ROI conversation made easy
Business buyers always wants to know the value. Now I can instantly pull ROI examples from our support docs:
Find all references to time savings, efficiency gains, or cost reductions in our support documentation.
Create 3 customer scenarios showing:
- Time before Browse AI
- Time after Browse AI
- Hours saved per month
- Equivalent cost savings
Use only metrics mentioned in our actual documentation.
Educational content that actually teaches
I use our docs to create learning paths:
Design a 5-day Browse AI learning path for someone who wants to [GOAL].
Using our documentation:
- Day 1: Fundamental concepts to understand
- Day 2-5: Hands-on tutorials in order
- Practice exercises for each day
- Mini-project to prove mastery
Link to relevant support articles for each step.
Preemptive troubleshooting guides
Nothing frustrates users more than hitting a wall. I proactively create troubleshooting content:
What are the 10 most common issues users face with [FEATURE/WORKFLOW]?
For each create:
- What the error looks like
- Why it happens
- How to fix it (step by step)
- How to prevent it next time
Pull everything from our support documentation.
How to build your own support database
Based on our actual Support Library setup, here's exactly how to do it. The complexity depends on how your support site is structured:
Understanding capture list vs. capture text
Before we dive in, here's the key distinction:
- Capture List: use this when you're grabbing multiple similar items (like a list of article links).
- Capture Text: use this for individual pieces of content (like an article's title or body).
Scenario 1: Simple structure (homepage → articles)
If your support site lists all articles on one page:
- Navigate to your support homepage
- Create a robot and select one article link
- Choose "Capture List" to grab all similar links
- Train pagination if articles span multiple pages
- Create a second robot for article content using "Capture Text"
- Connect them with a workflow
Scenario 2: Multi-tier structure (categories → article lists → articles)
This is more common and what we actually deal with. Your support site might have:
- Main page with category links
- Category pages with article lists
- Individual article pages
Here's how to handle it:
Robot 1: Capture all category URLs
- Go to your support homepage
- Create a robot that captures all category links
- Select one category link and choose "Capture List"
- Run it to get all category URLs
Robot 2: Capture article URLs from each category
- Go to any category page
- Create a robot that captures all article links
- Use "Capture List" for the article links
- Handle pagination within categories if needed
Robot 3: Extract the actual article content
- Open any individual article
- Create a robot using "Capture Text" for:
- Article title
- Full article body
- Metadata (last updated, category, tags)
Connect everything with workflows:
- Robot 1 → Robot 2 (categories feed into article lists)
- Robot 2 → Robot 3 (article lists feed into content extraction)
This three-robot setup handles even complex documentation sites. The beauty is you set it up once and can re-run it anytime to get updated content.
Step 4: Export and prepare for AI
- Download your complete dataset as CSV
- Do a quick cleanup (remove duplicate headers, navigation elements)
- Upload to your preferred AI tool
For our support site, this captured 100+ articles across multiple categories, giving me a complete knowledge base to work with.
The prompts I actually use every day
For product updates:
We just launched [FEATURE]. Using the support docs, write:
- One explanatory sentence
- Three specific benefits (not generic)
- One limitation to be transparent about
- A sample use case
For comparison content:
Compare how Browse AI handles [FEATURE] with [COMPETITOR FEATURE] based on documentation:
- What specific steps are different?
- What can each do that the other can't?
- Which is easier to set up?
No marketing fluff, just facts from the docs.
For technical translation:
Translate this technical capability from our API docs into marketing language:
[PASTE TECHNICAL SECTION]
Explain:
- What it lets customers do (in plain English)
- Why they'd want to use it
- A non-technical example
- Any prerequisites in simple terms
For feature discovery:
Based on the support documentation, what Browse AI features would help someone who needs to [USE CASE]?
List features with:
- What it does
- Why it's relevant for this use case
- Any setup considerations
What I learned
Let me be honest about what this doesn't solve:
- You still need to review everything. AI makes stuff up sometimes, even with good data
- The initial setup takes a few hours
- If your docs are bad, your output will be bad (garbage in, garbage out)
But here's what it does do:
- Cuts my content creation time by 80%
- Ensures I'm using correct product information
- Helps me find gaps in our documentation
- Gives me a starting point for everything
- Lets me write about technical features without an engineering degree
