An Assistant That Got the Numbers Right
IFPG's members ask about franchise costs, and the assistant was reading markup instead of meaning, mixing up one financial figure for another. We cleaned the data before the model ever saw it, then taught the prompt to show its work.
The problem
A Member Asking What a Franchise Costs Was Getting an Answer Built From the Wrong Number.
The listings feeding the assistant were exported straight out of the website, markup and all. The model was reading tags as if they were content, and with several money fields sitting side by side in the same record it could not reliably tell one from another.
Long conversations made it worse: context piled up until answers started borrowing from earlier questions. For a membership that makes six-figure decisions off these numbers, a confidently wrong figure is the one failure the product cannot absorb.
The solution
One Clean Pipeline Feeding One Disciplined Assistant
A preprocessing pipeline sits between IFPG's franchise listings and the model. It strips the markup out of the JSON export and standardizes every money field, while the original records stay exactly as they are for the website to render.
On top of that clean data, the prompt framework decides how each question gets answered: which template applies, which worked examples to show, and which field the answer has to be traceable to. Ambiguous questions get a clarifying reply instead of a guess.
The result streams back through a conversational interface built to sit inside IFPG's existing PHP site and ride its automated daily update, so the members' route to an answer never changes, only the answer does.
What the system delivers
Clean JSON the model can read
Tags stripped, money fields standardized, every record validated against a schema, with processing logs and validation reports to show what changed.
Answers that name their source field
Reasoning steps in the prompt, worked examples that separate one financial figure from another, and verification flags for quality control.
A streaming interface that fits the site
Real-time responses, visible loading and conversation states, and responsive layout compatible with the existing website.
Proof it improved, not a claim
Regression results on the queries that used to fail, accuracy and response-time metrics against the old system, and QA documentation that stays with IFPG.
What we built
Clean the Data, Then Make the Prompt Show Its Work
Six workstreams, none of which touch the source files: a preprocessing API that hands the model readable text, a prompt framework that forces it to reason before it answers, and a conversational interface that streams the result back into the site IFPG already runs.
01 · Preprocessing pipeline
The Model Reads Text, Not Markup
A custom API strips HTML from the JSON export while leaving the source files untouched for the website to render. Money fields get one standard format, every record is validated against a schema, and malformed entries fall back rather than fail. Large exports process in batches.
02 · Prompt framework
It Has to Name the Field It Used
Chain-of-thought steps make the reasoning explicit, and few-shot examples are chosen specifically to separate one money figure from another. Each question type gets its own template, verification checks confirm the right field was quoted, and old context is pruned so answers stop bleeding together.
03 · Conversational UI
Answers Arrive as They Are Written
A standalone interface streams responses in real time, marks clearly where one conversation ends and the next begins, and recovers state if the connection drops, with error messages a member can retry out of rather than a dead end.
04 · Integration and deployment
It Ships Inside the Site They Already Run
The assistant integrates with IFPG's existing PHP system and rides the automated daily update process already in place, so nothing about the members' route to it changes. Maintenance documentation ships with it.
05 · Testing environment
The Old Failures Became the Test Suite
A separate OpenAI Assistant instance runs development and testing so nothing experimental touches production. Historical problem queries are kept as regression tests, and validation metrics measure the improvement rather than assert it.
06 · Knowledge transfer
The Team Who Inherits It Can Run It
Training sessions with the stakeholders who will own the system, troubleshooting guides for the issues that actually recur, and documented best practices for refining prompts and data after we leave.
How it works
One Pass Over the Data, One Disciplined Route Through the Model
The export is cleaned and validated before it is ever sent. The question picks its template, the prompt carries its reasoning steps, and the answer streams back into the site the member is already on.
Built to hold up
The Requirements That Decide Whether It Survives Real Traffic
Security
TLS 1.2+ on everything in transit, sensitive configuration encrypted at rest, standard JSON responses with correct HTTP status codes.
Performance
Three seconds is the ceiling for a member's query, and the preprocessing pass has to finish inside the daily update window.
Scalability
Roughly 600 listings today, and past 1000 without a redesign; the pipeline batches rather than buckles.
Reliability
Fallbacks for the failures that actually happen: dropped connections, malformed records, and errors the member can retry out of.
Maintainability
Modular components, consistent patterns, and documentation written for the team who inherits it rather than the team who wrote it.
Recovery
Versioned configuration, regular backups, documented recovery steps, and a test environment that sees every change first.
The Questions It Used to Get Wrong Became the Test Suite
A separate OpenAI Assistant instance runs development and testing, so nothing experimental touches what members are using. Historical problem queries were kept as regression tests, and response quality is compared against the old system rather than judged on its own.
Accuracy and response time are both measured, failures are reported with enough detail to debug, and the QA documentation stays with IFPG so the checks continue after handover.
The outcome
Cleaner Data In, Fewer Escalations Out.
The assistant answers the same franchise database it always did. What changed is that nobody preps the data by hand anymore, financial questions stop getting mixed up, and a long conversation no longer falls over.
Reclaimed every week from manual data prep
Cleaning HTML tags and reformatting financial fields before each update is now automatic.
Fewer financial-data escalations
Worked examples and field-reference checks stop the assistant confusing one money figure for another.
Fewer long-conversation failures
History is pruned as a chat grows, so the conversation no longer breaks under its own weight.
Listing updates processed a week
The whole 600-listing dataset, refreshed daily, with no manual re-touch in between.
Fewer sessions abandoned on a dropped connection
The chat reconnects and restores where the member left off instead of ending the session.
Saved onboarding each stakeholder
Training sessions, QA notes, and troubleshooting guides shipped with the build, not after it.
Questions we get asked
What Teams Ask Before They Fix a Chatbot Like This
Do we have to restructure our data first?
No. The pipeline processes the existing JSON export and leaves the source files untouched, so everything the website renders stays exactly as it is. Data integrity at the source stays with IFPG; the cleaning happens on the copy the model sees.
How does it stop confusing one money figure for another?
Three ways at once: financial fields get one standard format during preprocessing, the prompt carries worked examples chosen specifically to separate those fields, and a verification check confirms the answer quoted the field it should have.
What happens in a long conversation?
Context is pruned rather than allowed to pile up, each query is handled independently, and the interface marks clearly where one conversation ends and the next begins, so answers stop borrowing from earlier questions.
How fast is it, and how far does it scale?
Three seconds is the ceiling for a member's query, and the preprocessing pass has to finish inside the daily update window. It runs on roughly 600 listings today and is built to pass 1000 without a redesign, batching large exports rather than choking on them.
What happens when something breaks?
Malformed records hit fault-tolerant parsing and fallback templates instead of failing the batch. Dropped connections reconnect and recover state, and response errors come back as a message a member can retry out of rather than a dead end.
How do you prove the new version is better?
A separate OpenAI Assistant instance runs development and testing, the queries that used to fail are kept as regression tests, and response quality and speed are measured against the old system, with the QA documentation handed over so the checks continue after handover.
Is Your Assistant Answering From Clean Data?
30 minutes, and you will know where yours is going wrong.
Related work
