Describing your need to AI: what makes the difference

1

The description matters more than the technology

When an application is assembled by AI, technique is no longer the obstacle. AI knows how to create a screen, a list, a form, a calculation rule. What it does not know is how your company works. It assembles what it understands, and it understands what you tell it.

Ask for “an application to manage my interventions” and you will get a generic screen, correct and useless: a list of interventions with a title, a date and a status. Nothing about how your technicians are assigned, what happens when the customer is not there, or who decides to invoice a wasted trip.

Describe the result you expect, the people who will use the application and the constraints in the field, and you will get something else: an application that follows your way of working. The difference between the two is not a matter of technology. It is a matter of description.

AI does not guess your business. It reads it in what you tell it.

2

The five elements of a good description

A good description is not long. It is complete on five points, always the same, whatever the project.

1. 01
   The expected result

   What must be true at the end. For example: every intervention request gets a planned date and a technician within the day, and the customer is informed.

2. 02
   The people and their roles

   Who uses the application and for what. The front desk records, the manager plans, the technician consults and closes, accounting invoices.

3. 03
   The objects handled

   The concrete things you talk about: a customer, a site, a piece of equipment, a quote, an intervention. Name them the way your team names them.

4. 04
   The rules and the exceptions

   What happens normally, and what happens when things do not go normally. An absent customer, a missing part, an intervention outside the contract.

5. 05
   What requires human approval

   What must never happen without a person approving it: sending a quote, granting a discount, closing a disputed file.

If you can answer these five points, you already have the essentials. The rest, AI proposes.

3

Show, don’t only tell

A real document says more than a page of explanations. What you use today, even imperfect, already contains your fields, your steps and your habits.

• An existing quote: it shows your lines, your terms, your mandatory mentions.
• The spreadsheet you keep by hand: its columns are your objects, its tabs are often your steps.
• A screenshot of the current tool: what you are missing is as visible there as what works.
• An example of a difficult case: the file that caused trouble last month is worth ten abstract rules.

Bring your vocabulary too. If your team says “file”, “intervention” or “purchase order”, say it that way. AI reuses your words in the screens, the lists and the messages. The day the application arrives, your team recognises it instead of having to learn it.

4

Ask before building

The best description is not written in one go. It is built in a conversation. Before assembling anything, AI must ask its questions: who approves this quote, what happens if the customer cancels, is a history of changes needed. Then it proposes an outline that you review.

Answering “I don’t know” is an acceptable answer. You do not have to settle every rule before starting. A sensible default is proposed, and you adjust it when the case comes up.

Prefer small successive requests to one giant request. A first version that handles the normal case, then an exception, then an approval rule: each step stays readable and verifiable. A giant request produces an application nobody has time to review.

5

The knowledge that stays attached to the project

What you explain once should not be repeated with every request. Your rules, your roles, your preferred wording, the things to avoid: all of this forms your company’s knowledge, and it stays attached to the project.

In practice, if you said that no discount is granted without the manager’s agreement, every later evolution respects that rule without you having to repeat it. If you said your customers are called “members”, the word does not change on the third screen.

That knowledge is also what keeps AI within its scope. It sees what you have allowed, and nothing more. We detailed this principle in What an AI assistant must know before it acts: allowed context matters more than a brilliant but isolated answer.

6

In Neoo: describe, structure, test, validate

At Neoo, this conversation takes place in Neoo Forge, the workshop that assembles your applications with AI. You describe your need in your words. Forge structures it into objects, screens, rules, roles and journeys, then shows you the outline before assembling anything.

Once assembled, the application is tested: normal cases, exceptions, the permissions of each role and rollback. Your team validates before anything goes live. We describe the full approach in Build a business application without coding and how to evolve the application safely in Modify, validate, roll back.

That description fits in a few lines. It is enough for Forge to propose an outline, ask the remaining questions and assemble a first version that you check. Discover the workshop on the Neoo Forge page or book a demonstration to see it with your own case.