The LouLou Method

A colleague receives another quote. The supplier sounds familiar. So does the product. But why did we pass on it last time? What did the price include? Was there a problem with the sample? The answers are scattered across spreadsheets and conversations.

AI can quickly organize the new document. Without the earlier evidence, however, it still does not know how to compare it.

That is the gap I want to close: turn the information, decisions and open questions from one sourcing task into records the next person can retrieve, check and update.

I'm Louis. LouLou is the shared name I give my AI collaborators. LouLouis.ai brings those names together and also reads as “LouLou is AI.” I bring business judgment and take responsibility for the work; LouLou helps me research, organize and move it forward.

The LouLou Method is an evolving approach drawn from real projects. It is not software that already handles an entire purchasing operation, or a fixed industry standard.

The database holds facts and history. The knowledge layer explains their meaning and conditions of use. A workflow organizes the current task. Review and updates preserve what the next task needs.

1. A supplier database: more than names and phone numbers

A useful supplier record should answer: Which entity does this name refer to? What have we checked? Who has been in contact? What terms were quoted? What happened when we worked together?

My internal database already organizes suppliers, contacts, project relationships, quotes, evidence and outcomes separately. Several distinctions matter:

• Checked is not the same as worked with. Public information, supplier statements and actual project experience need separate records.
• Similar names do not establish identity. Chinese names, English names, storefront names and other trading names should only be linked when evidence supports the relationship.
• A quote is not an isolated number. Specifications, quantity tiers, pricing units, currency, trade terms, dates and original documents belong with it.
• Not selected does not necessarily mean unsuitable. A client changing direction, a specification mismatch and unresolved terms are different reasons. Keeping the reason prevents misleading conclusions later.

A new quote should not silently replace an old one. Nor should a new recommendation erase a previous decision. Changes need to remain explainable.

2. An ontology: helping AI understand what belongs together

“Ontology” sounds technical. My plain-language explanation is: help AI understand which supplier, product and project a quote belongs to—and which conditions must be checked before using it to make a judgment.

Project requirements → Product specifications → Supplier quote
                                                      ↓
                                           Sources and applicable rules
                                                      ↓
                                           Human decision → Outcome

This is a conceptual model, not a claim that every step is automatically synchronized.

Connections alone are not enough. Confirmed client requirements, working assumptions and missing information must remain distinct. Superseded rules need a version history. Conflicting records need an unresolved issue and someone responsible for resolving it—not an AI quietly choosing the most convenient answer.

For example, “compare prices directly only when specifications and quote terms are sufficiently aligned” is a conditional rule. It belongs at the comparison step, not buried deep in an old conversation. Different teams may set different rules; who can approve and change them must also be clear.

3. Workflows: give AI a task whose output can be checked

I usually do not start with “finish this whole project.” I break it into units that can be reviewed.

A workflow card should identify:

• Inputs: Required records, including missing fields that prevent a judgment.
• Actions: Reading, organizing, cross-checking or drafting a proposal.
• Outputs: The table or card to deliver, and where its evidence belongs.
• Boundaries: What AI may suggest and where it must pause for a person.
• Updates: What is worth retaining and who reviews it before it enters the records.

AI can expand research directions, organize candidates and inspect reference links. I make selections, correct the rules and decide what can go into client materials. AI can highlight differences between quotes, but when terms are missing, the right output may simply be “not yet comparable.”

Prompts and skills carry out these tasks. The business rules and acceptance criteria need ongoing work—not just the wording or length of the prompt.

4. Quality and updates: turn a mistake into a checkable question

When AI applies a storefront's general capabilities to a specific product, correcting one row is not enough. I turn the mistake into a review question: Is there product-level evidence for this claim, or only a store-level description?

When one selection rule is incorrectly applied across different budget conditions, the rule needs a clearer scope.

I have internal business questions and evaluation records for checking sources, missing information, rule applicability and decision boundaries. They help expose weaknesses; they are not a public accuracy guarantee. After a rule changes, earlier problems need to be checked again, rather than judging the new answer by how fluently it reads.

The following is entirely fictional teaching material. It does not represent a real supplier, quote or project, or a recording of a live product.

A colleague receives a new quote from “Supplier A” and wants to know whether to continue the discussion.

The useful result is not always an immediate “choose this supplier.” Sometimes it is recognizing that there is not enough evidence yet.

This is not about pouring every conversation into a knowledge base. I would rather start with one specific action, such as reviewing a new quote or a claim about supplier capability.

1. Fix the source and time. Keep the original document location, receipt date, provider and permission for this use. Put source IDs next to extracted fields; a fluent AI summary is not a substitute for the original.
2. Identify the business object. Name the legal entity, product version, project requirement and quote tier. When a name or model does not match, do not merge records yet.
3. Turn the claim into checkable questions. “Customizable” leads to: which model, which process, what quantity conditions, and is there a written reply or sample?
4. Record the person's decision and why. AI may suggest “continue RFQ / pause / exclude,” but the owner should retain the decision, its applicable conditions and next action—not just a final status.
5. Write back only after approval, then retest old questions. Preserve earlier versions when new evidence arrives. If this task exposed a mistake, add an acceptance check and see whether it catches similar earlier problems.

The smallest useful artifact may be one sheet with source ID, entity ID, claim, evidence, state, gap, owner and decision date . Making these fields reliable is easier to test than promising an automatic supplier score.

Existing internal practice: Supplier database structures and working files, organized business objects and rules, some workflow implementations, human approval points, historical update records and internal evaluation materials. The two anonymous case studies show how parts of this approach have been used in research and client proposal preparation.

Still being improved: Ongoing organization of historical records, reading and writing across tools, consistency between written rules and implementation, and day-to-day maintenance. I do not claim that all business data is synchronized in real time, or that every documented rule is already enforced automatically.

The next validation step: Testing whether other teams can use the approach reliably with their own categories, client requirements and ways of working. Small implementations and reviews come before deciding what should become a repeatable product.

I want to keep testing whether the approach remains understandable and useful when the category, project or person using it changes.

I will start with a limited set of authorized records and four concrete questions: Can colleagues find the evidence? Does AI merge records incorrectly? Do missing terms stay visible? Can new outcomes be retained after approval?

Scope, permissions, ownership and acceptance criteria still need to be explicit. This does not automatically include supplier outreach, client quotations, purchasing or replacing the purchasing lead's decisions.

I will keep documenting new findings and corrections here. Before giving the system a bigger name, I want to see how it holds up in the next real task.

Related practice: From research to a reviewable proposal · Keeping sample records and client proposals aligned · Four more field notes · Try the Supplier Evidence Card