The Most Common Reasons Chatbot Projects Fail — and How to Fix Them
A Practical Guide for Law Students Who Are Not (and Do Not Need to Be) Programmers
Adapted from materials developed for the AI Law and Policy Clinic, University of Michigan Law School.
Most people who set out to build a chatbot assume the hard part is technical: choosing a platform, configuring settings, connecting APIs. Those steps are real, but they are not where most chatbot projects fail.
Projects fail in the documents.
Not because the documents are wrong, exactly. Because they were never designed to be read by machines. A PDF that looks perfectly clear to you may be nearly unintelligible to the system you are asking to answer questions from it. A policy document that your colleagues navigate effortlessly may confuse a chatbot into producing answers that are confident, plausible, and wrong.
The failures are not random. They cluster around a handful of specific, avoidable errors. This guide identifies them.
A note on audience: this guide is written for non-technical practitioners — lawyers, policy professionals, advocates, and law students who are building or overseeing chatbot projects without a background in software engineering or AI. It grew out of materials developed for the AI Law and Policy Clinic at the University of Michigan Law School, where these problems arise with increasing regularity. It is a bridge to best practices, not a comprehensive technical treatment. Readers with coding skills and experience in machine learning will recognize that many of the processes described here can be automated, extended, or optimized — systematic testing frameworks, for instance, can be substantially more sophisticated than what is described in Error #7. That depth is real and worth pursuing. The goal here is narrower: to get people into this space and build systems that work, without requiring them to become engineers first.
How a Chatbot Actually Works
Before diagnosing what goes wrong, it helps to understand the mechanism.
When a chatbot answers a question, it is not retrieving a memorized answer from training. It searches a collection of documents you have provided, identifies the passages it considers most relevant to the question, and generates a response based on those passages. This process is called Retrieval-Augmented Generation, or RAG. The chatbot is only ever as good as the documents it searches.
This means the quality of the chatbot’s answers is constrained, at every moment, by the quality of the documents it draws upon. A chatbot cannot produce accurate, specific answers from vague, messy, or outdated source material. Every user interaction is downstream of every document decision.
The relevant concept is signal-to-noise ratio. Useful, relevant, clearly structured information is the signal. Everything else — outdated drafts, duplicative content, formatting artifacts, scanned images with no readable text, documents that have nothing to do with what users will ask — is noise. More documents do not produce better answers. They produce more noise. The errors described below are, in different ways, all failures to understand this.
Error #1: Failing to Define the Scope
Before a single document is selected, converted, or loaded, one question must be answered: what, precisely, is this chatbot for?
This is a front-end requirement, not a planning nicety. Every decision that follows — which documents to include, which to exclude, how to structure them, how to test the system — depends on having a clear, written account of the chatbot’s purpose. Without it, there is no basis for any of those decisions. Everything seems potentially relevant. Nothing gets excluded. The system gets built on guesswork, and its answers reflect that.
A well-defined scope specifies three things: who the users are, what questions they will ask, and what questions the chatbot should not attempt to answer. The third element is as important as the first two. A chatbot without explicit exclusions will attempt to answer questions for which it has no reliable basis, and it will do so confidently.
Compare these two framings:
Vague: “A chatbot that helps people find information about our organization.”
Specific: “A chatbot that helps prospective law students find answers about J.D. admissions, including application requirements, deadlines, financial aid, and curriculum. It will not answer questions about current student records, faculty employment, or legal advice.”
The first framing could justify including every document the organization has ever produced. The second immediately narrows the corpus to admissions guides, financial aid summaries, curriculum descriptions, and FAQ pages — and explicitly excludes faculty handbooks, internal memos, and HR policies. Every subsequent document decision now has a principled basis.
A useful self-test: can you complete this sentence with specific, bounded language?
“This chatbot will answer questions about [specific topics] for [specific audience], drawing on [specific document types], and will not attempt to answer questions about [specific exclusions].”
If any blank produces a response like “everything related to our work,” the scope is not yet defined. Stop here. The errors that follow are all, in one way or another, downstream of skipping this step.
Prompt: Stress-Testing Your Scope
“I am developing a scope statement for a chatbot. Here is my current draft: [paste your draft]. Evaluate it against these criteria: (1) Is the target audience specific enough to guide document selection decisions? (2) Are the topics bounded, or could they expand indefinitely? (3) Are the exclusions explicit enough that a document reviewer could apply them consistently? (4) Does anything in this statement create ambiguity about whether a given document should be included or excluded? Identify the weakest elements and suggest a revised version that addresses them.”
Error #2: Dumping Every Document You Have Into the System
The scope is defined. Now comes the error that most immediately follows from ignoring it—or treating it as optional.
An organization gathers every document it possesses — every policy, every draft, every archived newsletter, every internal memo, every version of every form — loads them into the chatbot system, and waits for capability to emerge from the volume. It does not. Vast collections of documents rarely, if ever, result in a production system that can be trusted.
What emerges instead is a system that confidently retrieves the wrong thing: that surfaces an outdated policy because it was technically responsive to a query, that blends contradictory information from multiple versions of the same document, that returns a tangentially relevant passage when the directly relevant one exists three files away but was outcompeted in retrieval by sheer noise.
The instinct to be comprehensive is understandable. It feels responsible. It feels thorough. It is neither. Loading an undifferentiated collection of documents into a chatbot does not give the system more to work with; it gives the system more to be confused by. Every irrelevant document is a potential wrong answer. Every outdated document is a source of misinformation delivered with the same confidence as accurate information. Every draft sitting alongside a final version introduces uncertainty that the system has no way to resolve. The chatbot cannot distinguish signal from noise. That work falls to the people building. It also follows from the scope definition established by Error #1.
Error #3: Loading Documents Machines Cannot Read
Even a well-scoped, deliberately curated document collection will fail if the documents themselves cannot be read by the system processing them. This is a technical constraint, but its consequences are entirely practical.
Humans are remarkably good at interpreting documents under adverse conditions. We skip irrelevant headers, mentally connect footnotes to their references, understand a table by scanning it visually, and filter out page numbers without thinking. We do all of this automatically.
Software does none of this. When a chatbot system ingests a document, it processes a stream of text characters in sequence. It has no visual perception and no ability to infer structure that is not explicitly encoded. A document that appears perfectly clear to a human may yield garbled, fragmented, or nonsensical text when parsed by a parsing system.
The gap is particularly severe with formats that dominate legal and policy work.
PDFs are the most common and problematic. A PDF is fundamentally a set of rendering instructions: it tells software where to place each character on a page, but it does not encode logical structure. Paragraph boundaries, heading hierarchies, reading order, and table relationships exist visually but not structurally. Two PDFs that look identical on screen may have entirely different internal encodings.
The consequences are specific. Tables may be read across rows when the data is organized by columns. Multi-column layouts get read straight across the page, interleaving text from separate columns into incoherent sentences. Page headers and footers get interspersed with body paragraphs, interrupting text mid-thought. Scanned documents are worse still: they are images of text, not text itself, and are entirely invisible to a chatbot without optical character recognition (OCR) first converting the image.
Excel spreadsheets store data in a grid, but the meaning of that grid depends on human conventions — which row contains headers, which cells are labels, and what formulas connect values. A chatbot cannot reliably interpret these conventions. Data immediately legible to a human familiar with the spreadsheet’s context may yield a confusing sequence of disconnected numbers when processed by the system.
Word documents are the most tractable format because they explicitly encode structural information: headings, paragraphs, and lists are distinct elements. A clean Word document is a reasonable starting point. Heavily formatted files with text boxes, embedded objects, or tracked changes can still produce problems.
The Fix: AI-Powered Parsing
The most effective tool for converting complex documents into clean, structured text is LlamaParse, developed by LlamaIndex (cloud.llamaindex.ai). Unlike traditional extraction tools that apply rules and heuristics, LlamaParse uses large language models to interpret document structure — identifying tables, distinguishing headers from body text, and handling multi-column layouts. For small batches, the web interface requires no programming knowledge: upload a file, download the result. A free tier covers up to 1,000 pages per day, which is sufficient for most small-to-moderate projects.
Two qualifications are worth stating. LlamaParse is powerful but not infallible; complex tables and unusual layouts still warrant review after conversion. It is also a commercial service, which raises data privacy considerations that organizations handling sensitive materials should evaluate before adoption.
The output format is Markdown — addressed in the next section.
Error #3: Not Knowing What the Machine Is Seeing
Even when documents are converted correctly, a common error is skipping review of the output. This is where familiarity with Markdown becomes practically relevant — not as a technical skill, but as basic quality-control literacy.
Markdown is not a coding language. It is a writing format: a way of adding structure to plain text using a small set of symbols. A # at the start of a line marks a heading. Words wrapped in **double asterisks** appear bold. A series of words separated by pipe characters (|) becomes a table. That is essentially the entire system.
You are almost certainly already reading Markdown without knowing it. Every time an AI system responds with a formatted heading or a bulleted list, it is generating Markdown, which your browser renders into the visual formatting you see. Markdown is, in effect, the native language of AI systems.
It is also the format the chatbot will actually process. When you review a converted document in Markdown, you are looking at exactly what the system will work from. A heading that appears prominent in the original PDF may have converted to plain body text, meaning the chatbot will not weight it as a heading and will not use it to organize answers. A table that reads clearly to you may have become a jumbled sequence of words. Catching these errors requires enough familiarity with Markdown to recognize when something has gone wrong, not the ability to produce it from scratch.
For viewing Markdown output, no specialized software is required. StackEdit works directly in a browser: paste the converted text and see the raw and rendered versions side by side. Google Docs renders Markdown natively — paste Markdown text directly into a Google Doc, and it converts automatically, which makes it a convenient option for anyone already working in the Google ecosystem. If a platform requires a Word document upload, Google Docs can export to Word as well. That said, any platform requiring Word documents is almost certainly converting them to plain text on the backend anyway. The Word file is a surface-level interface requirement; what the system actually processes is the text inside it.
Prompt: Post-Conversion Review
“Here is the text extracted from a PDF document [paste the Markdown text]. I need to check whether the conversion was accurate. Identify any content that appears garbled, any tables that did not convert correctly, any headings that appear to have been lost or demoted to plain text, and any places where text from page headers or footers appears to have been mixed into the body content. For each issue, show me where it occurs and describe what it should look like.”
Prompt: Understanding Markdown as a Non-Technical Reader
“I am a law student working on a chatbot project. I have converted a PDF to Markdown and need to review it for errors, but I have no programming background. Explain what correct Markdown structure looks like for a legal or policy document. What are the most common conversion errors I should watch for, and what do they look like in the raw text? Give me three specific before-and-after examples of errors — showing what the flawed Markdown looks like and what the corrected version should look like.”
Error #4: Polluting the Corpus
A parsed and correctly converted document collection can still undermine chatbot performance if it contains incorrect content. This error takes several forms.
Including outdated material. An outdated policy document loaded alongside a current one will cause the chatbot to retrieve and cite superseded information, often without indicating that the information is no longer in effect. The system has no mechanism to distinguish old from current unless that distinction is encoded in the documents themselves or in their metadata. The fix is straightforward: replace old versions rather than accumulating them. If historical versions must be retained, mark them explicitly as superseded.
Including drafts alongside final versions. A draft document introduces ambiguity about which version is authoritative. The chatbot will treat them equally.
Including scope-adjacent material. Documents that are valuable for other purposes but outside the chatbot’s defined scope dilute retrieval precision. Every document the system must search through is a potential source of irrelevant results.
Inconsistent terminology. If some documents refer to “clients,” others to “participants,” and others to “service recipients,” the chatbot may fail to connect related information when a user asks a question using any one of those terms. Standardizing terminology across the corpus before loading documents is one of the highest-return preparation steps available.
Missing metadata. Each document includes a brief block at the top that specifies its title, source, date, and main topics. This helps the system understand what a document is about before examining its full text, improving retrieval precision. The format, called YAML front matter, looks like this:
---
title: Immigration Relief Eligibility Criteria
source: Michigan Immigrant Rights Center
date_updated: 2025-11-15
document_type: Practice Guide
topics: immigration, asylum, relief eligibility
---
Documents that are too large. A 200-page manual loaded as a single document performs less well than the same manual broken into its constituent chapters. Smaller, focused documents yield more precise retrieval. Each section should be self-contained enough to be meaningful on its own.
The prompts below can be used to audit documents for these problems before loading them — or to assess whether a document warrants inclusion at all.
Prompt: Scope Alignment
“My chatbot has the following purpose: [paste your scope statement]. Review this document against that purpose. Identify which sections are directly relevant and should be included, which sections are only marginally relevant and might be excluded, and which sections are clearly outside the scope and should be removed. For any section where the decision is not obvious, explain your reasoning.”
Prompt: Content Audit
“Review this document for chatbot suitability. Flag any content that appears outdated, that contradicts what is said elsewhere in the document, or that is likely to produce inaccurate or confusing chatbot responses. Also identify passages that assume background knowledge a general user of the chatbot would not have. For each issue you identify, explain the problem and suggest how to address it.”
Prompt: Terminology Audit
“Identify all cases in this document where the same concept is referred to by different terms or names. List each case and the variants used. Also identify any acronyms or specialized terms that are used without being defined, and that a general user of the chatbot would be unlikely to know. Suggest how to address each issue.”
Prompt: Generating Metadata
“Based on the content of this document, generate a metadata block with the following fields: title, source (if identifiable from the document), document_type, date_updated (if the document mentions one), and a topics list of five to eight keywords that describe its main subject areas. Format it between triple-dash lines as standard YAML front matter.”
Prompt: Segmentation Guidance
“This document is lengthy and I need to break it into smaller, focused sections for a chatbot knowledge base. Smaller sections produce more precise answers. Recommend how to divide this document, providing a short title and a one-sentence description for each proposed section. Each section should be focused enough that a user asking a specific question would find it useful on its own.”
Error #5: Skipping the Pre-Load Audit
One of the highest-return steps in document preparation is also one of the least commonly taken: using an AI system to audit documents before converting or loading them.
The approach requires no technical skill. Upload a document to Claude, ChatGPT, or any AI system that accepts file uploads, describe what the chatbot is intended to do, and ask the system to assess whether the document is suitable and identify any problems. An AI system can identify structural issues that are not obvious on visual inspection: inconsistent heading levels, sections that blend multiple topics, tables likely to convert poorly, and content that is outdated or contradicts other documents in the collection. It cannot make judgment calls on your behalf, but it flags issues for a human reviewer to resolve — faster than manual review alone.
Prompt: Structural Analysis
“I am preparing this document for use in a chatbot knowledge base. Analyze its structure without any technical jargon. Tell me: How is the content organized? Is the organizational logic consistent throughout, or does it shift? Are there sections that mix several unrelated topics together? Are there any features of this document — such as tables, footnotes, or multi-column layouts — that are likely to cause problems when converted from PDF to plain text? Describe each issue in plain language and explain why it matters for chatbot use.”
Running this audit before investing conversion and cleanup effort in a document that turns out to be unsuitable is among the most practical time-saving steps in the entire workflow. It is also easily skipped, because the impulse to move directly from document collection to loading is strong. Resist it.
One practical note: AI systems can process only a certain volume of text in a single session. For very long documents, work through them in sections. For the kinds of documents most common in legal and policy contexts — briefs, eligibility guides, FAQ pages, practice manuals — this limit is rarely a constraint.
Error #6: Skipping the Test
A chatbot loaded with well-prepared documents still requires systematic testing before deployment. Most projects skip this step, or conduct it informally — asking a few questions, observing that the answers seem reasonable, and declaring the system ready.
Informal testing is not testing. It finds the questions the chatbot handles well. Systematic testing finds the questions it handles poorly, and those are the only ones that matter for identifying what still needs to be fixed.
Effective testing begins with the scope definition and derives questions directly from it. The test set should include the specific questions users will actually ask — and questions the chatbot should decline to answer, to verify that the exclusions are enforced.
Prompt: Generating a Test Question Set
“I have built a chatbot with the following purpose: [paste scope statement]. Generate a test question set of 20 questions: 12 questions that represent realistic queries from the target audience and that the chatbot should be able to answer from its documents; 4 questions that are adjacent to the defined scope but outside it, which the chatbot should decline; and 4 questions designed to probe common failure modes, such as questions requiring synthesis across multiple documents, questions involving recently updated information, or questions that use terminology that may vary across documents. For each question, note what a correct or appropriate response would look like.”
When a test question produces a poor answer, the diagnosis usually points to one of three causes: the relevant information is not in the corpus (a curation problem); the relevant information is present but was not retrieved (a structure or metadata problem); or the relevant information was retrieved but was not usable by the system (a document quality problem). Each diagnosis points to a different remediation — and each is addressable using the preparation strategies described above.
The Pattern Across All Seven Errors
Each of the errors above is recoverable. None requires technical expertise to address. What they share is a single underlying cause: the assumption that building a chatbot is primarily an act of accumulation — gather documents, load them, connect the system, deploy. It is not. It is an act of curation.
The most common version of this mistake is also the most visible: the organization that loads everything it has and wonders why the results cannot be trusted. Vast document collections do not produce capable chatbots. They produce systems that are impressive in demonstration and unreliable in practice — systems that return something for every query, that sound authoritative, and that are wrong often enough that no one can depend on them. That combination is worse than a system that simply says it does not know. A system that users cannot trust produces no value, regardless of how often it happens to be correct. And a system that is sometimes correct but unpredictably so trains users to distrust every answer, including the accurate ones.
The preparation work described here — defining scope, curating deliberately, converting and reviewing documents, auditing before loading, testing systematically — is not overhead. It is the difference between a chatbot that serves as a reliable tool and one that is a liability. Do less, more carefully. That is the work.
Prompt Reference: All Prompts in This Guide
The following collects every prompt from the sections above for convenient reference. Each is designed to be used directly: copy it, fill in any bracketed placeholders with your specific content, and paste it into an AI system with your document uploaded or attached.
Stress-Testing Your Scope
“I am developing a scope statement for a chatbot. Here is my current draft: [paste your draft]. Evaluate it against these criteria: (1) Is the target audience specific enough to guide document selection decisions? (2) Are the topics bounded, or could they expand indefinitely? (3) Are the exclusions explicit enough that a document reviewer could apply them consistently? (4) Does anything in this statement create ambiguity about whether a given document should be included or excluded? Identify the weakest elements and suggest a revised version that addresses them.”
Post-Conversion Review
“Here is the text extracted from a PDF document [paste the Markdown text]. I need to check whether the conversion was accurate. Identify any content that appears garbled, any tables that did not convert correctly, any headings that appear to have been lost or demoted to plain text, and any places where text from page headers or footers appears to have been mixed into the body content. For each issue, show me where it occurs and describe what it should look like.”
Understanding Markdown as a Non-Technical Reader
“I am a law student working on a chatbot project. I have converted a PDF to Markdown and need to review it for errors, but I have no programming background. Explain what correct Markdown structure looks like for a legal or policy document. What are the most common conversion errors I should watch for, and what do they look like in the raw text? Give me three specific before-and-after examples of errors — showing what the flawed Markdown looks like and what the corrected version should look like.”
Scope Alignment
“My chatbot has the following purpose: [paste your scope statement]. Review this document against that purpose. Identify which sections are directly relevant and should be included, which sections are only marginally relevant and might be excluded, and which sections are clearly outside the scope and should be removed. For any section where the decision is not obvious, explain your reasoning.”
Content Audit
“Review this document for chatbot suitability. Flag any content that appears outdated, that contradicts what is said elsewhere in the document, or that is likely to produce inaccurate or confusing chatbot responses. Also identify passages that assume background knowledge a general user of the chatbot would not have. For each issue you identify, explain the problem and suggest how to address it.”
Terminology Audit
“Identify all cases in this document where the same concept is referred to by different terms or names. List each case and the variants used. Also identify any acronyms or specialized terms that are used without being defined, and that a general user of the chatbot would be unlikely to know. Suggest how to address each issue.”
Generating Metadata
“Based on the content of this document, generate a metadata block with the following fields: title, source (if identifiable from the document), document_type, date_updated (if the document mentions one), and a topics list of five to eight keywords that describe its main subject areas. Format it between triple-dash lines as standard YAML front matter.”
Segmentation Guidance
“This document is lengthy and I need to break it into smaller, focused sections for a chatbot knowledge base. Smaller sections produce more precise answers. Recommend how to divide this document, providing a short title and a one-sentence description for each proposed section. Each section should be focused enough that a user asking a specific question would find it useful on its own.”
Structural Analysis
“I am preparing this document for use in a chatbot knowledge base. Analyze its structure without any technical jargon. Tell me: How is the content organized? Is the organizational logic consistent throughout, or does it shift? Are there sections that mix several unrelated topics together? Are there any features of this document — such as tables, footnotes, or multi-column layouts — that are likely to cause problems when converted from PDF to plain text? Describe each issue in plain language and explain why it matters for chatbot use.”
Generating a Test Question Set
“I have built a chatbot with the following purpose: [paste scope statement]. Generate a test question set of 20 questions: 12 questions that represent realistic queries from the target audience and that the chatbot should be able to answer from its documents; 4 questions that are adjacent to the defined scope but outside it, which the chatbot should decline; and 4 questions designed to probe common failure modes, such as questions requiring synthesis across multiple documents, questions involving recently updated information, or questions that use terminology that may vary across documents. For each question, note what a correct or appropriate response would look like.”