Plan an AI Customer Support Chatbot

Create a business analysis document for a simulated AI customer support chatbot.

Introduction

30 Second Summary

When support answers are scattered, customers repeat themselves. Staff spend time chasing basic details while unresolved questions pile up.

In this project, you will create one copy-ready business analysis document in Word for the web for a simulated AI customer support chatbot. Its five connected deliverables trace the proposed service from common customer requests through human support, launch, measurement, and improvement.

What You'll Build

When you finish, you can present one polished document that traces a customer request from the first message through automated help to a human handoff.

By the end of this project, you'll have:

An Intent & FAQ List you can walk through to show how five customer requests map from sample phrasings and recognized entities to an answer, action, or handoff.
A complete order-status dialog flow that you can read from the opening question to a status result or human handoff, including missing-information and failure paths.
A stakeholder-ready operating plan you can present to explain the required integrations, staff preparation, staged rollout, and post-launch measurements.
Secret Mission: An optional edge-case challenge where you test unclear, abusive, incomplete, unavailable, and human-handoff scenarios to turn simulated failures into a structured improvement log.

Are there any prerequisites?

You need a Microsoft account plus internet access on your Windows device. Step 1 covers browser access to Word for the web, with no desktop installation, chatbot platform, API access, or live company system required.

Before We Start

This step locks in the scope of a simulated AI customer support chatbot with no fictional company, vendor, live endpoint, unsupported policy, or performance target. Your five deliverables are the Intent & FAQ List, Sample Dialog Flows, Integration Requirements Summary, Training Plan & Rollout Plan, and Post-launch Report Outline.

Set Up the BA Deliverable

Your chatbot analysis has five deliverables. Without a shared structure, their scope can drift as you work.

A single structured document keeps the five deliverables together. Its fixed sections help you keep unrelated assumptions out.

You'll use Word for the web in your browser. Its automatic saving stores the document in OneDrive as you shape each section.

In this step, get ready to:

Access Word for the web with your Microsoft account.
Create the named BA document.
Add the five deliverable headings.

Open Word for the web

Word for the web runs in your browser. No desktop installation is required for this setup.

Your Microsoft credentials stay on Microsoft's sign-in page, so you never copy them into the project document.

Navigate to office.com/login by entering it in your browser's address bar.
Press Enter.
Use the account-creation option on the sign-in page if you do not have a Microsoft account.
Complete the account prompts shown by Microsoft if you are creating an account.
Sign in with your Microsoft account.
Select Word on the signed-in page.

You'll see Word for the web open in your browser. The page is ready for you to create a document.

Can't Open Word for the Web?

Reload the sign-in page after confirming that your internet connection works.
Return to office.com/login if Word does not open after sign-in.

Help me troubleshoot access to Word for the web.

Create the document structure

The document title identifies your project. The five headings give every requested deliverable a dedicated place.

Create a blank document by choosing the blank-document option in Word.

You're in. The empty page is now the home for your complete BA deliverable.

Select the current document title at the top of the page.
Replace the current title with Project A: AI Customer Support Chatbot.

You'll see the new title at the top of the page. Word for the web saves the document to OneDrive automatically.

Copy the five section headings from the block below:

Intent & FAQ List
Sample Dialog Flows
Integration Requirements Summary
Training Plan & Rollout Plan
Post-launch Report Outline

How Does This Structure Help?

Each line reserves one section for a required deliverable. Keeping the headings in this order gives your later work a fixed home.

Paste the copied headings into the blank page.
Pause for Word for the web to save the changes automatically.

You'll see five separate headings on the page. Their order matches the reference block.

Headings or Title Look Wrong?

Remove the pasted text if the headings appear on one line.
Copy the reference block again to preserve its line breaks.
Re-enter Project A: AI Customer Support Chatbot if the title at the top differs.

Help me fix my Word document structure.

Keep the Simulation Boundary

Your document remains a simulation.

No fictional company enters the scope.
No chatbot vendor is selected.
No live company system is defined.
No endpoint value is added.
No unsupported policy detail is added.
No performance target is set.

Before you scan the page, can you recall the exact order of the five deliverables?

Scan the document from top to bottom.

You'll see Project A: AI Customer Support Chatbot at the top. All five headings are visible in the order shown above.

That's the foundation in place. Your BA document now has a clear boundary for every deliverable.

Your five-part BA workspace is ready. Next, you'll turn the first heading into a scenario-based Intent & FAQ List.

Build the Intent and FAQ List

The document framework is ready in Word for the web. Now you need to turn customer questions into a scope the chatbot can follow.

A static FAQ can return approved information. Order status also needs customer data plus a back-end action.

This table makes that boundary visible.

In this step, get ready to:

Create the six-column Intent & FAQ List table.
Document the five scenario-supported customer intents.
Check each row against the project boundaries.

Create the six-column table

Switch back to the Word for the web document from the previous step.
Place your cursor on the blank line directly beneath Intent & FAQ List.
Select the Insert tab in the ribbon.
Select Table.
Choose a six-column by six-row grid.
Enter Intent, Example customer phrasings, Entities, Intended answer or action, Handoff condition, plus FAQ source across the first row.

You should see one header row with five blank rows beneath it.

Table has the wrong size?

Select a cell beside the missing area.
Use Insert Below or Insert Right under Table Tools and Layout.

Help me correct the size of my Word for the web table.

Classify the five customer intents

An intent captures what the customer wants to achieve. An entity captures a value needed to understand or complete that request.

Before you compare the first two rows, do you think an approved FAQ alone can return a customer’s current order status?

Compare the information needed for Order status with the information needed for Password reset.

An approved FAQ can supply password-reset instructions. A current order status depends on the customer’s order number plus data from the order database.

Complete the Order status row with these values:
Complete the Password reset row with these values:

The first two rows now expose two response types. Password reset uses approved content. Order status requires customer data plus a database action.

Complete the Refund policy row with these values:
Complete the Basic troubleshooting row with these values:

The refund row now protects missing policy details with TBD by the company. The troubleshooting row captures the product name without inventing a product catalogue.

Complete the Human-agent handoff row with these values:

You should now see five populated intent rows. The FAQ source cells remain for the final scope check.

Add the FAQ sources

The source column shows where approved response content could come from. It also prevents unsupported company policies from slipping into the simulation.

Enter at least one approved source label in every FAQ source cell: FAQs, help center articles, or past chat transcripts.
Replace every unprovided refund-policy detail with TBD by the company.

Before you review the finished table, which row do you expect to depend most clearly on customer data?

Review the five intent names against the supplied scenario.
Check every row for example phrasings, entities, an intended answer or action, plus a handoff condition.
Confirm that the order-status row asks for an order number before retrieving status from the order database.
Confirm that every source cell uses only the three approved source labels.

You should see five completed rows with every required column populated. The order-status row should show the clearest dependency on customer data plus a back-end action.

See unsupported details?

Replace every invented refund rule with TBD by the company.
Remove any fictional company, chatbot vendor, live endpoint, or target value.

Help me check this Intent & FAQ List for unsupported assumptions.

Solid work. Your table now protects the simulation from unsupported assumptions.

Next, you’ll turn the order-status row into a complete conversation with success, missing-information, failure, plus human-handoff paths.

Create the Sample Dialog Flow

The completed Intent & FAQ List now shows what the simulated chatbot should recognize. A customer still needs a complete route from their question to a result.

An order-status request needs more than recognition. The flow must collect the order number before it can present a status.

Missing details can stop the request. Failed requests also need a route to human support.

In this step, get ready to:

Write the successful order-status conversation.
Add a retry path for a missing order number.
Create a failure path that leads to human support.

Write the successful order-status path

A dialog flow maps each customer input to the next response or action. The main path shows the shortest route to a successful result.

Switch back to the Word for the web document from earlier.
Select the blank line directly below the Sample Dialog Flows heading.
Type Order status: main path as the path label.

The new label separates this conversation from the other deliverables in your document.

Type Customer: Where is my order? as the first turn.
Type Chatbot: Please provide your order number. as the response.

The first exchange now connects the recognized request to the information needed for the lookup.

Type Customer: <order number> as the next turn.
Type Chatbot action: Request the status from the order database using <order number>. as the lookup action.

The flow now identifies the order database as the source of the status. It does not invent a live endpoint.

Type Chatbot: Your order status is <order status>. as the successful result.
Read the main path from the customer's question to the status response.

You should see a complete sequence that requests an order number before returning <order status>.

Add the missing-information path

A missing-information path keeps the conversation moving when the required order number is absent. It gives the customer another chance before offering human handoff.

Place your cursor below the completed main path.
Type Order status: missing-information path as the path label.

The document now has a separate branch for a request that cannot reach the lookup stage.

Type Condition: The customer does not provide an order number. as the starting condition.
Type Chatbot: An order number is required to check the order status. Please provide your order number. as the retry response.

The first missing-information response explains what is required. It also gives the customer a clear next action.

Type Condition: The request still cannot proceed because no order number is provided. as the second condition.
Type Chatbot: I cannot continue the order-status request. I can connect you with a human agent. as the handoff offer.

The missing-information branch now ends with human support when the lookup still cannot proceed.

Complete the failure and handoff path

A failure path covers an unavailable status or any point where the chatbot cannot help. A CRM ticket or conversation transfer preserves the available context for the human agent.

Place your cursor below the missing-information path.
Type Order status: failure path as the path label.

The final branch now has a clear place in the written conversation.

Type Condition: No order status is returned or the chatbot cannot help. as the failure condition.
Type Chatbot: This request needs human support. as the customer message.

The customer now receives a clear explanation when the automated request fails.

Type Chatbot action: Transfer the conversation or create a CRM support ticket. as the escalation action.
Type Chatbot action: Pass the available conversation information to the human agent. as the context-sharing action.

The handoff now preserves the information already collected. The customer does not need to restart the conversation without context.

Before you review the branches, predict whether any path still ends without a next action.

Read the main path from Customer: Where is my order? to the response containing <order status>.
Read the missing-information path from the absent order number to the human-handoff offer.
Read the failure path from the unavailable result to the transfer of conversation information.

You should see the main path return <order status>. You should see both unsuccessful paths lead to human support with a clear next action.

You have turned the order-status intent into a complete conversation with success and handoff outcomes. Next, you will document the integrations that make those actions possible.

Document the Integration Requirements

Your order-status conversation now covers the customer path from question to result. It also handles missing information and human handoff.

The written flow still needs integration requirements before a technical team can connect it to real data. These requirements also define how a failed handoff reaches support.

In this step, get ready to:

Create a table for the systems that support the chatbot conversation.
Map the support knowledge base, order database, CRM, website, and app.
Define safe failure behavior for every integration.

Inspect the missing connections

An integration requirement maps one system boundary. It names the data sent and returned at that boundary.

Before you review the flow, do you expect it to give a technical team enough detail to connect every system?

In the Word for the web document from earlier, read the order-status path from the customer question through the returned status.
Review the failure path that creates a CRM ticket.

You'll see the order database and CRM named. The flow leaves each data exchange undefined.

A table makes those data exchanges visible. It also gives every unknown API endpoint a clear placeholder.

Create a five-row, six-column table below Integration Requirements Summary using the table control in the top ribbon.
Enter these headings in the first row: System, Purpose, Data sent to the system, Data returned, API endpoint, and Failure response.
Review the first row of the table.

You should see six labeled columns ready to capture each system boundary.

Document the named systems

Each row ties a named system to one responsibility. Keeping the scope to the scenario protects the document from vendor assumptions.

Complete the Existing support knowledge base row with Return approved support content for Purpose, Customer question or matched intent for Data sent to the system, Approved FAQ, help-center, refund-policy, password-reset, or troubleshooting content for Data returned, and TBD by the technical team for API endpoint.
Complete the Order database row with Retrieve order status for Purpose, Order number for Data sent to the system, Order status for Data returned, and TBD by the technical team for API endpoint.
Review the first two system rows.

You should see a clear boundary between approved support content and dynamic order data.

Complete the CRM row with Support unresolved requests and human handoff for Purpose, Unresolved issue and available conversation information for Data sent to the system, Support-ticket or handoff result for Data returned, and TBD by the technical team for API endpoint.
Complete the Website and app row with Send customer messages to the chatbot and display chatbot responses or human-handoff results for Purpose, Customer messages for Data sent to the system, Chatbot responses or human-handoff result for Data returned, and TBD by the technical team for the integration method in the API endpoint column.
Review all four system rows.

You should now see the existing support knowledge base, order database, CRM, website, and app represented without any invented technical details.

Why Keep the Integrations Tool-Neutral?

The scenario names business systems without selecting a chatbot platform. Keeping unknown endpoints as TBD by the technical team preserves that boundary.

A technical team can replace each placeholder after confirming the real architecture.

Define safe failure behavior

A failed integration changes the customer's next step. A clear message plus human handoff keeps the chatbot from inventing information.

Complete every Failure response cell with this requirement: If the integration fails or is unavailable, show a clear customer message and offer human handoff. Do not fabricate an answer.

Before the final review, which technical details do you expect to remain unresolved?

Confirm the System column covers the existing support knowledge base, order database, CRM, website, and app.
Confirm every row records its purpose, data sent, and data returned.
Confirm every unknown endpoint or integration method is marked TBD by the technical team.
Confirm every failed or unavailable integration shows a clear customer message and offers human handoff.

You'll see a complete Integration Requirements Summary with no invented endpoints. Every failure has a customer-facing response plus a route to human support.

That's the technical gap closed: your order-status flow now has documented data exchanges and safe failure paths.

Your integrations now have clear data boundaries and safe failure paths. Next, you'll turn the chatbot scope into staff training, rollout, and post-launch measurement plans.

Write the Training, Rollout, and Post-launch Plans

Your Word for the web document now maps the chatbot's supported conversations to the systems needed behind the scenes.

Correct flows alone do not reduce agent workload unless staff understand the chatbot's scope. A controlled rollout keeps the launch manageable.

Post-launch measurement shows where customers still need help. This step completes the document with the plans needed to train staff, manage the release, and track results.

In this step, get ready to:

Write a Training Plan for staff support activities.
Build a staged Rollout Plan with stakeholder placeholders.
Create a Post-launch Report Outline using the supplied metrics.

Write the staff Training Plan

The Training Plan turns your documented scope into repeatable staff activities. Approved training data keeps future improvements grounded in reviewed customer-support material.

In the Word for the web document from earlier, place your cursor beneath Training Plan & Rollout Plan.
Type Training Plan on its own line.

You should now see a dedicated Training Plan section beneath the existing deliverable heading.

Add Supported intents and limits covering the five documented intents with their existing boundaries.
Add Human-handoff process explaining how staff receive unresolved requests with the available conversation information.

Your first two activities define what the chatbot supports. They also show staff when responsibility moves to a human agent.

Add Reviewing conversation failures as a regular staff activity.
Add Logging incorrect answers as a required record of response problems.

The plan now gives staff a consistent way to capture conversations that fall short.

Add Refining responses as the activity for correcting approved chatbot content.
Add Adding approved training data as the activity for expanding future coverage.

That is a useful milestone. Your Training Plan now turns chatbot limits and failures into specific staff responsibilities.

Build the staged Rollout Plan

A staged rollout gives the support team time to validate behavior before a wider release. Unknown scheduling decisions stay visible as stakeholder work.

Type Rollout Plan on its own line beneath the final training activity.
Add the stage Validate FAQs and dialog flows with the support team.

You should now see the first rollout gate beneath the Training Plan.

Add the stage Test the website, app, order database, CRM, and handoff.
Add the stage Conduct a controlled launch.

The rollout now checks the documented connections before limiting the first release to a controlled launch.

Add the stage Review feedback and failures.
Add the stage Proceed to wider release after stakeholder approval.

You should now see all five rollout stages in sequence.

Add Date: TBD with business stakeholders beneath every stage.
Add Owner: TBD with business stakeholders beneath every stage.

Each stage now makes its unresolved timing and ownership decisions visible.

Add Acceptance targets: TBD with business stakeholders beneath every stage.

Your Rollout Plan now has a controlled path from support-team validation to stakeholder-approved release. Every unknown decision is clearly assigned for later agreement.

Create the Post-launch Report Outline

The Post-launch Report Outline defines what stakeholders review after release. Section headings establish the measurement structure without inventing results or target percentages.

In the same document, place your cursor beneath Post-launch Report Outline.
Add the section Reporting period.

You should now see the first reporting section beneath the existing heading.

Add the section Chatbot usage.
Add the section Chatbot resolution rate.

The outline now has places to record adoption and successful chatbot resolution.

Add the section Average handle time for bot versus human.
Add the section Fallback rate.

You should now see sections for comparing handling time and tracking conversations that fall back.

Add the section Customer feedback ratings.
Add the section Failures or incorrect answers.

The report can now capture customer reactions and response problems after release.

Add the section Improvements made from user feedback.
Add the section Next actions.

The outline now connects observed problems to completed improvements and future work.

Before the final review, consider which section you expect to contain the most stakeholder placeholders.

Review the Training Plan against the six required staff activities.
Review the Rollout Plan against the five required stages.
Check every rollout stage for all three TBD with business stakeholders fields.
Review the Post-launch Report Outline against the nine required sections.

You should see staff training activities, five staged rollout gates, and every supplied reporting metric. Dates, owners, acceptance targets, performance results, and target percentages remain uninvented.

That completes the planning layer. Your document now covers chatbot scope, conversation behavior, integrations, staff readiness, rollout, and post-launch measurement.

Secret mission

Test Edge Cases and Log Improvements

Put your written chatbot requirements under pressure with a reusable set of simulated edge-case tests. You will record deliberate failures. Each one becomes a classified entry in the Post-launch Report improvement log.

Clean Up Your Resources

The completed BA document has no ongoing project cost in Word for the web. Choose whether to keep the document in OneDrive, close it for later, or delete it.

Resources you used:

One Word for the web document named Project A: AI Customer Support Chatbot, stored in OneDrive.

Keep everything running

No action is needed. Choose this if you plan to refine the requirements or submit the document later.

Leave Project A: AI Customer Support Chatbot in OneDrive.
Continue editing the document whenever you want to update the simulated requirements or improvement log.

Pause - I'll come back to this later

This option ends the current editing session. Your document stays in OneDrive for the next session.

Return to the Word for the web document from earlier.
Wait until Word for the web confirms that your latest changes are saved.
Close the browser window.
Leave Project A: AI Customer Support Chatbot in OneDrive for your next session.

Delete - I don't want to use this again

This option removes the Word document if you no longer need the simulation. Permanent deletion removes your only stored project copy.

From Word for the web, return to your OneDrive file list.
Select Project A: AI Customer Support Chatbot.
Use the selected document's Delete action.
Open the OneDrive recycle bin.
Permanently remove Project A: AI Customer Support Chatbot from the recycle bin.
Confirm that the document no longer appears in your OneDrive file list.
Confirm that the document no longer appears in the OneDrive recycle bin.

Nice Work!

You did it! Your simulated AI customer support chatbot document is complete in Word for the web with all five requested business analysis deliverables.

You learned how to:

Define an Intent & FAQ List with five scenario-supported customer-support intents. Capture example phrasings for each intent. Record the recognized entities. Specify the intended action. Set the human-handoff condition. Use only the approved FAQ sources.
Map the order-status conversation from the customer's first question to a status result or human handoff. Document the support knowledge base, order database, CRM, website, and app as required integration points. Keep unknown endpoints marked TBD by the technical team.
Prepare training, rollout, and post-launch plans for the proposed chatbot. Define staff preparation around chatbot scope. Document the handoff process. Stage a controlled rollout with unknown details marked TBD with business stakeholders. Structure post-launch reporting around the supplied metrics without inventing results.
Secret Mission: Simulate difficult customer conversations with a reusable Test and Improvement Log. Test unclear questions. Test abusive language. Test missing order information. Test unavailable results. Test explicit human-agent requests. Turn each failed result into a classified improvement for the Post-launch Report.

Ready to quiz yourself?