A conversational AI assistant embedded in the Webroot + Carbonite account portal, scoped to resolve the highest-volume onboarding and troubleshooting questions instantly. It reduced non-account-related calls by 60%, freeing the support team for the complex work, and was deliberately kept away from account and payment handling on ethical and privacy grounds.
As Webroot and Carbonite consolidated into a single OpenText account experience, the customer support team inherited a steady stream of repetitive questions: how to get started, which devices can be backed up, how to make an account change. These were high-frequency, low-complexity tickets, exactly the kind of work that clogs a queue, slows response times for genuinely urgent issues, and burns out support staff.
Users, meanwhile, didn't want to file a ticket and wait. They wanted an answer at the exact moment they hit friction, usually on the Downloads and Features page, mid-setup. The static FAQ wasn't being read, and the ticket queue was the wrong tool for questions that already had known answers.
The mandate was to design an on-brand conversational agent that could absorb the repetitive support load, resolving common questions instantly and freeing human agents to focus on complex, high-value cases. The challenge was doing this without the failure modes that make AI support feel worse than no support at all: confident wrong answers, an empty text box that invites off-topic questions, and hidden disclosure about what the AI can and can't do.
Resolve the highest-volume, lowest-complexity questions in-chat so they never enter the support queue.
Surface help where setup questions actually arise, the Downloads and Features page, not in a buried support section.
Carry the OpenText / Webroot + Carbonite identity while being honest about AI limitations and tightly scoped to real product tasks.
SupportBot is a conversational support agent embedded directly in the Webroot + Carbonite account portal, surfaced on the Downloads and Features page where users are most likely to have setup questions. Rather than routing users through a ticket queue or a static FAQ, the assistant offers immediate, context-aware help with product onboarding, setup, and troubleshooting in natural language.
The disclosure “AI-generated responses might vary” sits prominently at the top of the chat panel, directly below the assistant’s name and role label. Three suggested prompts reduce the blank-slate anxiety of an empty text field, anchoring users to real tasks, and to the exact scenarios that drive the most support volume, before they’ve typed a word.
These recordings are early working prototypes, built in late 2025 using Figma Make’s AI features, my first hands-on work with that toolset. Rather than mock up a static chat panel, I built a functioning assistant that composes a complete, step-by-step setup guide from a user’s question and then hands it off as a usable artifact: opened in a full window, or downloaded as a file the user keeps.
That shift matters for deflection. A chat reply scrolls away and gets asked again next week; a downloadable instruction set follows the user through a multi-step install and answers the follow-ups before they become tickets. Prototyping it live, instead of describing it in a spec, let the team see and pressure-test the interaction before committing engineering time.
Deflecting support load only works if users trust the answers and stay within the assistant’s competence. Four principles, set before any wireframes, kept SupportBot reliable enough to take real load off the support team.
SupportBot surfaces on the Downloads and Features page, the highest-friction moment in the account experience, rather than buried in a support section users only find after they’re already frustrated. Catching the question early deflects the ticket instead of escalating it.
The “AI-generated responses might vary” notice appears immediately below the panel header, not in a footer or terms page. Setting accurate expectations up front is what lets users trust the answers they do get, and keeps the assistant from over-claiming on questions it shouldn’t resolve alone.
Three pre-written task starters address the blank-slate problem, users tap to begin rather than formulate a question from scratch. Each prompt maps to a genuine high-frequency support scenario, steering users toward the exact questions the assistant resolves best and deflecting the most common tickets by design.
The assistant is explicitly scoped to Webroot and Carbonite product questions, and explicitly kept away from complex account and payment handling. That exclusion was deliberate: we did not want an AI assistant touching customers’ private personal information or making judgment calls on payment disputes, both on ethical grounds and to limit privacy risk. Narrowing scope also shrinks the hallucination surface, so the questions the assistant does answer, it answers reliably.
Building with AI tools exposed a gap that had nothing to do with code: the team was briefing AI features the way they briefed each other, in prose, tickets, and meeting notes. AI tools read structure. Unstructured input produces unpredictable output, and the debugging that follows is expensive.
I ran training for the development team on using Markdown as the product brief format for AI tools, treating headings, nested lists, and explicit hierarchy as the specification itself rather than as formatting. A well-structured Markdown brief gives the model unambiguous scope, ordered requirements, and clear constraints, so the team spent its time refining intent instead of re-prompting around bad output.
SupportBot reduced non-account-related calls by 60%. The repetitive onboarding, install, and troubleshooting questions that used to fill the queue now resolve in-chat, at the moment the user hits friction, without a ticket being filed.
60% reduction in non-account-related calls. The high-frequency, low-complexity questions the assistant was scoped to handle stopped reaching human agents.
Support capacity redirected to complex work. Agents were freed to focus on the challenging customer issues that genuinely need human judgment, rather than repeating the same setup instructions.
Account and payment issues stayed with people, by design. Complex account and payment cases were deliberately excluded from the assistant’s scope on ethical grounds and to avoid putting customers’ private personal information at risk. That boundary was a design decision, not a limitation, and it is part of why the deflection the assistant does handle is trustworthy.
