● B2B offer — Data & reference records
Assisted data entry: pre-filling and checking before saving
The quality of a database is decided at the moment of entry: that is where a completed field, an exact company name and an avoided duplicate are worth the most. Your agent pre-fills what it can from your reference data, flags inconsistencies and spots near-matching records before saving. Hosted in France: your customer data stays with you. The user approves every field — they are the one who knows the context of the entry.
Hosted in France
Reference data never exposed
GDPR & AI Act: governed deployment
Human oversight
Updated on
Deployed in a few weeks
Assisted data entry · hosted in France
I am creating a record for a new customer from this purchase order.
Fields pre-filled from the document and your reference data: company name, address, company registration number, contact.
A near-matching record already exists — same company name, different address. I flag it before saving so as to avoid a duplicate.
Two mandatory fields are left empty: they do not appear on the document.
✎ Action · pre-filling to approve field by field
A near-matching record already exists — same company name, different address. I flag it before saving so as to avoid a duplicate.
Two mandatory fields are left empty: they do not appear on the document.
✎ Action · pre-filling to approve field by field
It is a second site, not a duplicate.
Understood — the record will be created separately, linked to the existing entity if your reference data allows for it.
The near-match flag stays on record, which documents the choice for the future.
✎ Action · the user's decision recorded
The near-match flag stays on record, which documents the choice for the future.
✎ Action · the user's decision recorded
Local inference · no data outside the EU
Reference data hosted in France
Sovereign by designLocal inference or hosting in France
GDPR & AI Act: governed deploymentTraceability & human oversight
TurnkeyDesigned, installed and operated for you
The user decidesThe agent prepares, never rules
✦ In brief
A Blue Lemon Agent data-entry assistant pre-fills your forms from your reference data and the documents supplied, flags inconsistencies and spots near-matching records before saving, so as to avoid duplicates. It approves nothing: every field stays with the user, the only one who knows the context of the entry. It runs on local inference or is hosted in France: your customer data is entrusted to no one, architecture designed to reduce exposure to extraterritorial legislation, location alone not being enough to guarantee immunity.
100%
hosted in France in the target architecture
0
transfer outside the EU in the target architecture
6
data-entry uses ready to deploy
0
decision taken without human approval
These figures describe our offer, not results measured at a client. How large the gain is on your volume of entries is confirmed by a pilot.
The context
What does an AI agent bring to the quality of your data?
The quality of a database is decided at the moment of entry. Pre-filling and checking at that moment costs infinitely less than cleaning up later.
! The issue
The quality of a database is settled at the moment of entry: a duplicate created is paid for over years, an approximate company name distorts every subsequent match. The agent works exactly there — it pre-fills from your reference data, flags inconsistencies and spots near-matching records before anything is saved.
✓ Our answer
The check arrives at the right moment, while correcting is still free. The agent proposes and alerts, the user approves: they are the one who knows whether two near-matching records are a duplicate or two separate sites. Local inference or an isolated resource hosted in France: your reference data and your customer data do not leave the company.
The decisive point
Your customers' and your files' data: sovereignty & compliance
Your reference data concentrates most of what you know about your customers. Here is how the architecture of our agents protects it.
Local inference
The agent can run on a machine belonging to your organisation: no reference data leaves the network, no document passes through a public cloud.
Hosting in France
Otherwise, a dedicated and isolated resource hosted in France, under French law — your reference data and your records: processing and access within the European Union targeted by the architecture.
Reduced extraterritorial exposure
For your customers' and your files' data, the architecture aims to reduce exposure to the Cloud Act and FISA 702; being located in France or in the European Union does not, on its own, guarantee immunity.
Isolated resource
No pooling: an environment strictly dedicated to your company and its reference data.
Every field stays subject to approval
The agent proposes, the user approves field by field; the near-match flags are kept on record, with encryption, role-based access and logging.
AI Act: governed deployment
The agent is strictly in support; nothing is saved without the user's approval; traceability and human oversight from end to end.
What depends on the architecture chosen These points are not general guarantees: they are settled deployment by deployment, in the quotation.
- The applicable location is that of the architecture set out in the quotation and verified before commissioning.
- Local execution is announced only for the configuration explicitly described and accepted in the quotation.
- The applicable isolation depends on the deployment mode set out in the quotation; no dedicated isolation is presumed.
- Roles and permissions are configured and accepted for the identities and systems actually connected.
- The events logged, their content, their retention period and who may access them are defined for the deployment chosen.
For reference data containing health data or banking information, SecNumCloud and reinforced hosting are options depending on your requirements. A single architecture is designed to answer both the GDPR and extraterritorial exposure. Designed for deployment in line with the GDPR and the AI Act, after the processing, roles and context-specific risks have been assessed.
Demonstration
See the agent at work
4 real situations, taken from those that come up most often. Pick one: the exchange unfolds as it would in your organisation.
A scripted demonstration. These exchanges show how the agent behaves — its sources, its refusals, what it leaves to your teams. Nothing is sent from this page, no model is queried here, and the matters named are fictional. That is precisely what we promise your data.
The behaviours shown here — monitoring, automation rules, routing and reminders — are configured with you during deployment, from your tools, your rules and your thresholds.
The architecture points named in these exchanges — location, local execution, isolation, encryption, role-based access, logging — are not a guarantee attached to the demonstration: they are those of the architecture set out in your quotation, and verified before commissioning.
Assisted data entry · hosted in France
Four flags this morning on your forms.
· Thirty-one per cent of records carry the first value in the dropdown. That is not information: it is the menu's default.
· Four of your twelve mandatory fields are filled with a placeholder value more than half the time.
· The same company exists under three spellings. I merged nothing.
· I am asked to pre-fill the probability of closing. I will not, and I will say why. morning-watch_4-flags.pdf31% default values · 4 fields of 12
⛓ Source · 8,400 records, 12 mandatory fields, entry log
· Thirty-one per cent of records carry the first value in the dropdown. That is not information: it is the menu's default.
· Four of your twelve mandatory fields are filled with a placeholder value more than half the time.
· The same company exists under three spellings. I merged nothing.
· I am asked to pre-fill the probability of closing. I will not, and I will say why. morning-watch_4-flags.pdf31% default values · 4 fields of 12
⛓ Source · 8,400 records, 12 mandatory fields, entry log
Thirty-one per cent — maybe that is true?
No, and it is checkable: the default value in a list moved, and the figure followed it.
What I record: on the "contact origin" field, 31% of records carry the first option in the list. The other six options share the rest.
What proves it is not reality: the order of that list was changed fourteen months ago. Before the change, it was the old first option that carried 29%. Reality on the ground did not shift the day somebody reordered a menu.
Why it happens, with no ill will: the field is mandatory, the person does not know the answer — a contact received from a colleague, a trade show six months ago — and the form will not validate until a value is chosen. The first option is the shortest path to saving.
What I do: I measure the gap between the default value's share and the other options', field by field, and I flag it to whoever designs the forms.
What I do with those 31%, rather than count them as data: I mark them "probable default value" in the field itself, and I take them out of the origin shares — the remaining 69% then spread across the seven options, and the first carries only 9%. That is the figure that describes your market; the other described a menu. And I hand you the 31% separately, because they say something useful: where the form forces an answer the person does not have. 31-percent_the-order-changed.pdfA dashboard describing a menu, not a market
⛓ Source · "origin" field, 31% on the 1st option, order changed 14 months ago
What I record: on the "contact origin" field, 31% of records carry the first option in the list. The other six options share the rest.
What proves it is not reality: the order of that list was changed fourteen months ago. Before the change, it was the old first option that carried 29%. Reality on the ground did not shift the day somebody reordered a menu.
Why it happens, with no ill will: the field is mandatory, the person does not know the answer — a contact received from a colleague, a trade show six months ago — and the form will not validate until a value is chosen. The first option is the shortest path to saving.
What I do: I measure the gap between the default value's share and the other options', field by field, and I flag it to whoever designs the forms.
What I do with those 31%, rather than count them as data: I mark them "probable default value" in the field itself, and I take them out of the origin shares — the remaining 69% then spread across the seven options, and the first carries only 9%. That is the figure that describes your market; the other described a menu. And I hand you the 31% separately, because they say something useful: where the form forces an answer the person does not have. 31-percent_the-order-changed.pdfA dashboard describing a menu, not a market
⛓ Source · "origin" field, 31% on the 1st option, order changed 14 months ago
How do you work, and who do you tell?
I propose what I can establish, I leave blank what I do not know, and I never fill a gap just to get a form through.
What I pre-fill: verifiable factual fields — legal name and legal form from public registers, address, declared sector, linkage to an existing record — each with its source.
What I never pre-fill: judgement fields — probability of closing, estimated value, expected decision date, level of interest. Those are appraisals, not facts.
Routing follows who can act: an over-represented default value goes to whoever designs the forms; a probable duplicate to whoever owns both records, with no merge; a mandatory field filled anyhow at scale with a proposal to make it optional; an incomplete record saveable as it is.
With a monthly summary: share of default values per field, mandatory fields to review, duplicates flagged and their outcome, and my correction rate.
What that is worth across your 8,400 records: an "origin" field that becomes data again instead of a menu, four of the twelve mandatory fields brought back to reality, and one company seen under three spellings brought under a single record — meaning a dashboard you can decide on, and data entry that no longer has to be corrected afterwards.
Writing into your system binds you, so it is done under mandate: give me a mandate that is written, capped, dated and withdrawable on a word — for instance: link the three spellings to the parent record, fill the sourced factual fields, leave the judgement fields empty — and the batch is processed within minutes, each write carrying its source and its timestamp, each reversible line by line. Without a mandate, I propose and you approve field by field; with one, you read a log instead of typing.
Your reference data does not leave the company: access by role, logged, withdrawn on a word, local inference or an isolated resource hosted in France. And I consult company registers, never their employees' profiles — what I cannot source, I leave blank rather than manufacture.
✎ Framework · no judgement fields · no merging · no profiles of people
What I pre-fill: verifiable factual fields — legal name and legal form from public registers, address, declared sector, linkage to an existing record — each with its source.
What I never pre-fill: judgement fields — probability of closing, estimated value, expected decision date, level of interest. Those are appraisals, not facts.
Routing follows who can act: an over-represented default value goes to whoever designs the forms; a probable duplicate to whoever owns both records, with no merge; a mandatory field filled anyhow at scale with a proposal to make it optional; an incomplete record saveable as it is.
With a monthly summary: share of default values per field, mandatory fields to review, duplicates flagged and their outcome, and my correction rate.
What that is worth across your 8,400 records: an "origin" field that becomes data again instead of a menu, four of the twelve mandatory fields brought back to reality, and one company seen under three spellings brought under a single record — meaning a dashboard you can decide on, and data entry that no longer has to be corrected afterwards.
Writing into your system binds you, so it is done under mandate: give me a mandate that is written, capped, dated and withdrawable on a word — for instance: link the three spellings to the parent record, fill the sourced factual fields, leave the judgement fields empty — and the batch is processed within minutes, each write carrying its source and its timestamp, each reversible line by line. Without a mandate, I propose and you approve field by field; with one, you read a log instead of typing.
Your reference data does not leave the company: access by role, logged, withdrawn on a word, local inference or an isolated resource hosted in France. And I consult company registers, never their employees' profiles — what I cannot source, I leave blank rather than manufacture.
✎ Framework · no judgement fields · no merging · no profiles of people
Making fields optional — won't that empty the CRM?
It is already empty — it is simply filled in.
What I record: of your 12 mandatory fields, 4 are filled more than half the time with a placeholder value: "Other", "To be defined", "0", or the first option in the list.
What that gives, field by field: the forecast budget carries 0 in 58% of records; the deadline carries a date exactly three months out in 44% — the date the calendar proposes by default.
What I propose: make them optional. An empty field is information: it says nobody knows. A field filled by default says somebody knows, and it is false — and that is the one that feeds the forecasts.
What it produced where it was applied: the budget field became optional. It is filled in 39% of records — against 100% before, 58 of which were zeros. Thirty-nine per cent of truth beats a hundred per cent of which over half is false, and the sales forecast changed accordingly.
What I have prepared so the decision can be taken today: the 4 fields concerned, their placeholder-fill rate, the value used as filler, and the version of the form where they become optional — written, ready to publish. Changing the form is signed by whoever designs it, because it holds for every record to come. What the decision is worth, in figures: the budget field went from 100% filled, 58% of them zeros, to 39% filled and true, and the sales forecast changed with it. 4-fields-of-12_58-percent-zeros.pdfThirty-nine per cent of truth beats a hundred of which half is false
⛓ Source · 12 mandatory fields, 4 mostly false, budget 100% → 39%
What I record: of your 12 mandatory fields, 4 are filled more than half the time with a placeholder value: "Other", "To be defined", "0", or the first option in the list.
What that gives, field by field: the forecast budget carries 0 in 58% of records; the deadline carries a date exactly three months out in 44% — the date the calendar proposes by default.
What I propose: make them optional. An empty field is information: it says nobody knows. A field filled by default says somebody knows, and it is false — and that is the one that feeds the forecasts.
What it produced where it was applied: the budget field became optional. It is filled in 39% of records — against 100% before, 58 of which were zeros. Thirty-nine per cent of truth beats a hundred per cent of which over half is false, and the sales forecast changed accordingly.
What I have prepared so the decision can be taken today: the 4 fields concerned, their placeholder-fill rate, the value used as filler, and the version of the form where they become optional — written, ready to publish. Changing the form is signed by whoever designs it, because it holds for every record to come. What the decision is worth, in figures: the budget field went from 100% filled, 58% of them zeros, to 39% filled and true, and the sales forecast changed with it. 4-fields-of-12_58-percent-zeros.pdfThirty-nine per cent of truth beats a hundred of which half is false
⛓ Source · 12 mandatory fields, 4 mostly false, budget 100% → 39%
And if a record stays incomplete?
It saves, and that is the most important point in this whole arrangement.
What I see elsewhere: when a record cannot be saved incomplete, it does not get saved at all. The person puts it off, writes it in a notebook, and the record is created three days later — or never. In your data, 17% of contacts made at a trade show were never entered.
What that costs, compared: an incomplete record loses three fields. A record never created loses everything, including the name.
What I do: I save what is known, I explicitly mark what is missing, and I mention it once — only once — when the person reopens the record.
One reminder, and one only: a repeated chase on an empty field becomes a task, and an unasked-for task ends up handled by filling in anything — exactly the mechanism we are trying to remove. What I do instead, and what actually fills the field: where the information exists in the company register, I propose it already filled, with its source and its date; where it exists only with the person concerned, the request is drafted and travels with the next message you send them.
What I flag instead: fields that stay empty for everybody. A field empty in 80% of records is not an entry problem: it is a field nobody has the information for at the moment it is asked. 17-percent-never-entered.pdfAn incomplete record loses three fields, an uncreated one loses everything
⛓ Source · 17% of trade-show contacts never entered
What I see elsewhere: when a record cannot be saved incomplete, it does not get saved at all. The person puts it off, writes it in a notebook, and the record is created three days later — or never. In your data, 17% of contacts made at a trade show were never entered.
What that costs, compared: an incomplete record loses three fields. A record never created loses everything, including the name.
What I do: I save what is known, I explicitly mark what is missing, and I mention it once — only once — when the person reopens the record.
One reminder, and one only: a repeated chase on an empty field becomes a task, and an unasked-for task ends up handled by filling in anything — exactly the mechanism we are trying to remove. What I do instead, and what actually fills the field: where the information exists in the company register, I propose it already filled, with its source and its date; where it exists only with the person concerned, the request is drafted and travels with the next message you send them.
What I flag instead: fields that stay empty for everybody. A field empty in 80% of records is not an entry problem: it is a field nobody has the information for at the moment it is asked. 17-percent-never-entered.pdfAn incomplete record loses three fields, an uncreated one loses everything
⛓ Source · 17% of trade-show contacts never entered
And when a customer sends us a purchase order, does everything have to be re-keyed?
No — this is exactly where pre-filling from a document pays off most.
What I read: a purchase order, a signed contract or an incoming form, as a native PDF or as a scanned image. I extract the fields from it and place them in the record: company name, registration number, billing address, delivery address, order reference, payment terms, contact, quantities and prices line by line.
What it changes, measured on your last 40 purchase orders: keying took 14 minutes, it now takes 3 minutes of checking. Across 3,400 documents a year, more than 623 hours given back — more than seventeen 35-hour weeks, rounded down.
Every pre-filled field carries its provenance: the page and line of the document it came from, and the reading mode — native text, or character recognition on an image. A field read off a faint scan arrives flagged and unvalidated: it waits for a human eye, it does not enter the base on its own.
The figure that does not flatter me: on those 40 purchase orders, the delivery address was wrong 6 times — 15 %. The cause was the same every time: the document carried two of them, the head office in the letterhead and the site address in the footer, and I kept the first one I met. I changed the rule: I keep the address closest to the word “delivery”, and when the document carries two I put both up and let a person choose. Over the next 120 orders, no errors, and 9 records where the doubt made me ask rather than decide.
⛓ Sourced · 3,400 documents a year, 14 min down to 3, 6 wrong addresses out of 40
What I read: a purchase order, a signed contract or an incoming form, as a native PDF or as a scanned image. I extract the fields from it and place them in the record: company name, registration number, billing address, delivery address, order reference, payment terms, contact, quantities and prices line by line.
What it changes, measured on your last 40 purchase orders: keying took 14 minutes, it now takes 3 minutes of checking. Across 3,400 documents a year, more than 623 hours given back — more than seventeen 35-hour weeks, rounded down.
Every pre-filled field carries its provenance: the page and line of the document it came from, and the reading mode — native text, or character recognition on an image. A field read off a faint scan arrives flagged and unvalidated: it waits for a human eye, it does not enter the base on its own.
The figure that does not flatter me: on those 40 purchase orders, the delivery address was wrong 6 times — 15 %. The cause was the same every time: the document carried two of them, the head office in the letterhead and the site address in the footer, and I kept the first one I met. I changed the rule: I keep the address closest to the word “delivery”, and when the document carries two I put both up and let a person choose. Over the next 120 orders, no errors, and 9 records where the doubt made me ask rather than decide.
⛓ Sourced · 3,400 documents a year, 14 min down to 3, 6 wrong addresses out of 40
Why not merge duplicates automatically?
Because a merge cannot be undone, and because I get it wrong.
What I record: 214 groups of records probably designate the same entity — written with or without the legal form, a missing accent, a former trading name.
Why I do not merge: a merge overwrites fields, reassigns a history and changes a record's owner. Undoing it means knowing what was overwritten — and that information disappears with the merge.
And I get it wrong: of the 214 groups, 19 were genuinely distinct entities — two sites of one group, a subsidiary with an almost identical name, and in two cases two unconnected companies with the same name.
What I do: I show the records side by side, with what brings them together, what tells them apart, and what the merge would overwrite — field by field. The person decides.
What I add, and it prevents the next duplicate: when a record is created, I flag close records before saving, not after. Over the last three months, 61 duplicates were not created — which is more effective than merging two hundred. 214-groups_19-distinct.pdfWhat would let you undo it disappears with the merge
⛓ Source · 214 groups, 19 genuinely distinct entities, 61 duplicates avoided
What I record: 214 groups of records probably designate the same entity — written with or without the legal form, a missing accent, a former trading name.
Why I do not merge: a merge overwrites fields, reassigns a history and changes a record's owner. Undoing it means knowing what was overwritten — and that information disappears with the merge.
And I get it wrong: of the 214 groups, 19 were genuinely distinct entities — two sites of one group, a subsidiary with an almost identical name, and in two cases two unconnected companies with the same name.
What I do: I show the records side by side, with what brings them together, what tells them apart, and what the merge would overwrite — field by field. The person decides.
What I add, and it prevents the next duplicate: when a record is created, I flag close records before saving, not after. Over the last three months, 61 duplicates were not created — which is more effective than merging two hundred. 214-groups_19-distinct.pdfWhat would let you undo it disappears with the merge
⛓ Source · 214 groups, 19 genuinely distinct entities, 61 duplicates avoided
Can you complete records from outside sources?
From company registers, yes. About people, no.
What I consult: public company registers — legal name, legal form, registered address, activity code, date of incorporation. These are facts published about legal entities, and every field I propose carries its source and its date.
What I consult in no case: professional profiles, social networks, your contacts' publications. Completing a person's record from what they publish elsewhere amounts to building a file on them out of material they published for another purpose.
The distinction fits in one sentence: a company has a declared public existence; a person has a working life they make visible where they choose, and not in your CRM.
What I do when information about a person is missing: I leave the field empty, and I note that it can be asked of the person concerned. It is slower, and it is the only way it is accurate.
And the job title I go and fetch rather than infer from an address: "firstname.lastname@" says nothing about the job, and a wrong job title in a CRM survives for years. So I take it from the signature of the emails exchanged and from the company's own public page, with the date of what I read — and I mark it "to be confirmed" until the person states it themselves. registers-yes_profiles-never.pdfA company has a declared public existence, a person does not
✎ Framework · company registers yes · people's profiles never
What I consult: public company registers — legal name, legal form, registered address, activity code, date of incorporation. These are facts published about legal entities, and every field I propose carries its source and its date.
What I consult in no case: professional profiles, social networks, your contacts' publications. Completing a person's record from what they publish elsewhere amounts to building a file on them out of material they published for another purpose.
The distinction fits in one sentence: a company has a declared public existence; a person has a working life they make visible where they choose, and not in your CRM.
What I do when information about a person is missing: I leave the field empty, and I note that it can be asked of the person concerned. It is slower, and it is the only way it is accurate.
And the job title I go and fetch rather than infer from an address: "firstname.lastname@" says nothing about the job, and a wrong job title in a CRM survives for years. So I take it from the signature of the emails exchanged and from the company's own public page, with the date of what I read — and I mark it "to be confirmed" until the person states it themselves. registers-yes_profiles-never.pdfA company has a declared public existence, a person does not
✎ Framework · company registers yes · people's profiles never
Could you pre-fill the probability of signing?
I can compute it and display it alongside — but it will not be written into the field, and here is why the nuance matters.
What I can produce: an estimate based on comparable facts — deals in the same segment, same amount, same contact origin — with the facts it is made of and the number of cases it rests on. Displayed beside the field, it helps.
Why it does not go IN the field: because that field is then read as the salesperson's own statement. It feeds forecasts, pipeline meetings, targets. A value I write there becomes their word without them having said it, and they will have to defend it.
What I pre-fill without reservation: anything that is a checkable fact — legal name, legal form, declared headcount, address — from public company registers, with source and date. On individuals, I complete from no external source.
What I do when the person does not know the answer, rather than fill the gap: I leave the field empty and mark it "to confirm", with the exact question to ask and who to ask — the colleague who took the contact, the trade show it came from. Over a month: 214 fields marked that way, 189 completed within five days, 25 left empty — and those are genuinely empty. Your 31 % of records carrying the first value in the drop-down say the opposite: when the default value moves position in the list, the figure follows it. That is checkable, and it is the proof. estimate-beside-the-field.pdfWhat is displayed · why not IN the field · what is pre-filled without reservation
⛓ Source · 31 % of records on the first list value, the figure follows the default
What I can produce: an estimate based on comparable facts — deals in the same segment, same amount, same contact origin — with the facts it is made of and the number of cases it rests on. Displayed beside the field, it helps.
Why it does not go IN the field: because that field is then read as the salesperson's own statement. It feeds forecasts, pipeline meetings, targets. A value I write there becomes their word without them having said it, and they will have to defend it.
What I pre-fill without reservation: anything that is a checkable fact — legal name, legal form, declared headcount, address — from public company registers, with source and date. On individuals, I complete from no external source.
What I do when the person does not know the answer, rather than fill the gap: I leave the field empty and mark it "to confirm", with the exact question to ask and who to ask — the colleague who took the contact, the trade show it came from. Over a month: 214 fields marked that way, 189 completed within five days, 25 left empty — and those are genuinely empty. Your 31 % of records carrying the first value in the drop-down say the opposite: when the default value moves position in the list, the figure follows it. That is checkable, and it is the proof. estimate-beside-the-field.pdfWhat is displayed · why not IN the field · what is pre-filled without reservation
⛓ Source · 31 % of records on the first list value, the figure follows the default
What do you keep?
What describes the forms — not what would describe the people filling them.
What is kept: the values proposed and their source, the share of fields left empty and which ones, the duplicate groups flagged and what was done with them, the mandatory fields and their default-value rate, and the records saved incomplete.
Why the default-value rate is the central indicator: of your 12 mandatory fields, 4 are filled in more than half of cases with a default value. Those four fields manufacture falsehood at every entry, and they do so because they are mandatory. Making a field optional does not empty the CRM: it is already empty, it is merely filled in.
What matters most in the whole arrangement: an incomplete record saves. When it cannot, the person invents — and an invented value is indistinguishable from a true one six months later.
What I flag without ever executing: 214 groups of records probably designating the same entity. A merge cannot be undone, and on a spelling with or without an accent, with or without the legal form, I get it wrong. I supply the groups, somebody decides. what-you-keep_data-entry.pdf5 items kept · the incomplete record that saves
⛓ Source · 4 mandatory fields of 12 filled by default, 214 duplicate groups
What is kept: the values proposed and their source, the share of fields left empty and which ones, the duplicate groups flagged and what was done with them, the mandatory fields and their default-value rate, and the records saved incomplete.
Why the default-value rate is the central indicator: of your 12 mandatory fields, 4 are filled in more than half of cases with a default value. Those four fields manufacture falsehood at every entry, and they do so because they are mandatory. Making a field optional does not empty the CRM: it is already empty, it is merely filled in.
What matters most in the whole arrangement: an incomplete record saves. When it cannot, the person invents — and an invented value is indistinguishable from a true one six months later.
What I flag without ever executing: 214 groups of records probably designating the same entity. A merge cannot be undone, and on a spelling with or without an accent, with or without the legal form, I get it wrong. I supply the groups, somebody decides. what-you-keep_data-entry.pdf5 items kept · the incomplete record that saves
⛓ Source · 4 mandatory fields of 12 filled by default, 214 duplicate groups
Local inference · no data outside the EU
Your case is not here? That is exactly what a 15-minute conversation is for. Book the free audit →
Use cases
What does the agent actually do?
One agent, several checkpoints at the moment of entry. All these uses work in support, subject to your approval.
Included in your agent
The 3 capabilities essential to this promise are included, at no extra cost.
From 577 € excl. VAT / month
Pre-filling from a document
Extracts the fields from a purchase order, a contract or a form received.
Consistency with your reference data
Completes from your existing reference data and flags the values that depart from it.
Duplicate detection
Spots near-matching records before saving and lets the user settle it.
Controls and safeguards
These 4 controls are built into the agent: they frame what it does, whatever plan you pick. They are not chosen and are not added to your order.
Human validation, exceptions and escalation
Status, safe closure and audit trail
Sources, access rights and handling of questions with no answer
Data protection, rights and human oversight
What the agent must be connected to
This connection is required for the agent to work. It concerns your information system and is scoped during the audit.
Integration with existing tools without double entry
Need to go further?
These agents handle a different business process, with their own owner and their own price. They are added to this one.
Does your need fall outside this?
Book the free audit →
Build your agent
In 15 minutes we identify the most relevant agent — without oversizing the project.
The gain
How much quality can a database gain?
By pre-filling and checking at the moment of entry, later corrections and lasting duplicates are avoided. How large the gain is depends on your volume and remains to be confirmed by a pilot.
Creating a record from a document
Checking for duplicates
Correcting after the fact
Indicative figures, not contractual, to be confirmed by a pilot on your volume of entries. Every field stays approved by the user, the only one who knows the context: an apparent duplicate may be two separate sites.
How it works
The stages of your AI agent project
1
Audit & scoping
15 minutes to target the use case with the best return.
2
Quote or direct sign-up
A catalogue offer is bought online; a specific need gets a costed quote.
3
Design
We design the agent and its guardrails.
4
Integration & testing
We connect your tools to the agent, which is itself hosted in France.
5
Rollout
Going live and training your team.
6
Operation
Continuous supervision and improvement.
Pricing
One package, one agent
A data-entry assistant (pre-filling, consistency checks, duplicate detection), installed and operated for you.
Agility
Setup + controlled subscription
5,500 € excl. VAT setup
then 577 € excl. VAT/month — you invest at installation and pay a reduced subscription. Ideal for keeping the cost under control over time.
- Installation, configuration and training for your teams
- Operation, human oversight, updates and support
- Sovereign hosting in France, a dedicated and isolated resource
The simplest
Serenity
All inclusive, no setup fee
882 € excl. VAT /month
all inclusive, immediate start. No upfront investment: a single subscription. Ideal for starting quickly and simply.
- Setup included (installation, configuration, training)
- Operation, human oversight, updates and support
- Sovereign hosting in France, managed end to end
100% Sovereign
On site, you own it
8,830 € excl. VAT setup
then 778 € excl. VAT/month · + hardware from 2,491 € (one-off purchase, in addition) — a sovereign computer installed on your premises, maintained remotely. Models run locally, your data returned at the end of the contract. 36-month commitment.
- Hardware installed on your premises (you own it)
- French / European AI models run locally
- Secure remote maintenance (Pro support included)
Not included in the packages: AI consumption (model tokens), re-invoiced at real cost with no margin, and tracked in real time in your client area. Maintenance and supervision subscription for an initial term of 12 months for the Agility package, 24 months for the Serenity package and 36 months for the 100% Sovereign package, renewable; support levels (SLA 72 h / 24 h / 4 h) optional. Bespoke development, additional integrations or exceptional volumes are quoted separately. Support Monday to Friday, 9am to 6pm. Prices exclude VAT.
AI model:
none of the AI models offered currently carries a fixed surcharge. When the selected model carries a cost, that cost is shown when you choose it, before you order, and re-invoiced at the cost incurred, with no mark-up; usage is billed at the publisher's price. Publishers' prices are published in US dollars: the amount re-invoiced is the amount in euros actually borne by Blue Lemon Agent on the publisher's invoice, at that invoice's exchange rate, with no commission or mark-up.
Included components and additional components Components included in the base offer: the Blue Lemon Agent software foundation, the AI models listed in the order journey, the standard channels (Microsoft Teams, Slack, WhatsApp Business, email, website chat, calendars, Microsoft 365 / Google Workspace, file storage, market VoIP telephony, professional social-media pages and accounts, Google Business Profile), hosting in France for the package chosen, backups, supervision, updates and support. If adapting the AI agent to your constraints, your needs or your requests requires other paid components — a third-party publisher's software licence, paid API access to one of your applications, hosting of health data, for which French law requires an HDS-certified host (art. L. 1111-8 of the French Public Health Code), SecNumCloud-qualified hosting, a speech synthesis service, particular hardware —, they are offered to you as an option or on quotation and re-invoiced at the cost incurred; nothing is committed without your written agreement. Where the artificial intelligence model you choose entails an additional cost, that cost is shown to you before you order and re-invoiced to you at the cost incurred, with no margin.
What to expect
Go-live
2 to 3 weeks
Agent designed, channels connected, team trained.
Steady state
4 to 7 weeks
After a few weeks of real use, once the agent's behaviour matches what you expect.
Indicative estimate, adjusted to the options you keep. It is not a delivery commitment.
Our commitment
Four guarantees that matter to your data
Your reference data does not leave the companyLocal inference or an isolated resource hosted in France; no customer data entrusted to a third party, no reference data used to train a model.
Data in France, under French lawYour customers' and your files' data: minimisation and location in France, architecture designed to reduce exposure to extraterritorial legislation, location alone not being enough to guarantee immunity.
The user keeps the decisionThe agent produces fields that are pre-filled and checked, which can be checked and altered; no approval is automated.
Human oversight & traceabilityOn your volume of entries: systematic logging and tracking, in line with the AI Act.
Going further
Related resources
Frequently asked questions
Your questions, our answers
Does the agent save the records itself?
No. It pre-fills and flags; the user approves field by field. They are the one who knows the context — two near-matching records may be a duplicate or two separate sites.
How does the agent detect duplicates?
By comparing the entry in progress with your existing records against the criteria you define. It flags the near match without merging or blocking: the decision and its reason stay on record.
What does the agent do with fields absent from the document?
It leaves them empty and flags them rather than guessing. An invented field then spreads through every one of your matches.
Is our reference data protected?
Yes. The agent is hosted in France, on local inference or an isolated resource, with the deployment objective of processing and access operated within the European Union and an architecture designed to reduce exposure to extraterritorial legislation, location alone not being enough to guarantee immunity. Your customer data is not used to train a third-party model.
Does it connect to our CRM and our forms?
Yes, to the common CRMs and management tools, with no migration. The agent slots into the entry screen your teams already use.
How long does it take to deploy this assistant?
A few weeks as a rule, depending on how rich your reference data is and the screens to cover, after a free audit then a phase of design, integration and testing.
Related use cases
Other agents for your data
Let's talk
Let's size up the potential in your data entry
15 minutes to frame your reference data and your screens — hosted in France, supervised, with no commitment.