A Hebrew discovery meeting becomes a draft scope with open questions, not a quote. What the model may fill, what it must leave blank, and what it may not price.
Key takeaways
- An open question is an output of the meeting, not a sign of failure. Each one is attached to a specific line and blocks that line from being priced until it is answered.
- Four Hebrew words recur in discovery and cannot be priced as they stand: ליווי, תחזוקה, שוטף and הטמעה. All four sound agreed, and none of them defines a quantity, a frequency or a boundary.
- The Hebrew word כמה serves both as a question word and as a vague quantity. A sentence containing it is not data, and the model may not turn it into a number.
- There is a technical mechanism for forcing a blank: OpenAI's documentation states that every field in the schema must be required, and an optional field is emulated with a union type including null. So the model returns an explicit null instead of omitting.
- The person who signs off is named on the record, and the draft is stored separately from the quote that was sent so the difference can be shown.
A Hebrew discovery meeting produces a draft scope, not a quote. The model may phrase a description, split it into lines and propose a unit of measure, and it must leave the price, the date and the payment terms empty. Anything that was not said in the meeting leaves as an open question rather than as a reasonable completion.
Why a draft scope is not a quote
A quote is a document somebody can accept. A draft scope is a list of lines, some of which cannot yet be priced. The difference is not semantic: the moment a number appears beside a line it starts living a life of its own, even with the word estimate next to it.
So the draft holds three separate parts rather than one:
- Ready lines. A description, a quantity and a unit that were explicitly stated in the meeting. These are the lines a person can price without asking anything.
- Blocked lines. Lines that were mentioned but are missing a critical figure. They exist, they are shown, and their price is empty.
- Open questions. Each attached to at least one blocked line. A question attached to no line is a note, not a question.
That ordering changes the next meeting. Instead of sending a quote and collecting corrections, you send a short list of questions where each one blocks a line, and the client sees exactly what is holding up what.
Which Hebrew discovery words must never become a priced line?
The ones that sound like agreement while defining nothing countable. In an Israeli discovery call they show up almost every time, and both sides leave certain they understood each other.
| What was said | What is missing to price it | What enters the draft | Status |
|---|---|---|---|
| ליווי (accompaniment) | Hours per month, response time, for how many months | A line with no price | Blocked |
| תחזוקה (maintenance) | What is included, what counts as a fault, who decides | A line with no price | Blocked |
| שוטף (ongoing) | Frequency, and what happens when it is exceeded | A line with no price | Blocked |
| הטמעה (rollout) | How many users, how many training sessions, where | A line with no price | Blocked |
| Integration with a system | System name, direction, volume, who owns access | A line with no price | Blocked |
| Three screens in the admin panel | Nothing - it was counted | A line with quantity 3 | Ready |
| A weekly export to Excel | Nothing - it was counted | A line with a frequency | Ready |
The bottom two rows are the pattern. A ready line is one where a quantity or a frequency was stated. Everything else enters blocked, however strongly both sides felt they had understood one another.
There is a second Hebrew trap in the word כמה. English separates the question word from a vague quantity; Hebrew uses one word for both jobs. A sentence from the meeting containing it must leave as an open question, because there is no way to tell from a transcript whether a question was asked or a statement was made.
What may the model fill, and what must it leave empty?
The rule is short: it may phrase, it may not estimate. Phrasing reorganises what was said. Estimating invents what was not.
| Field | May the model fill it? | Where the value comes from |
|---|---|---|
| Line description in Hebrew | Yes | Quoted from the meeting, rephrased |
| Quantity | Only if explicitly stated | The meeting |
| Unit of measure | Yes, as a proposal to confirm | The service catalogue |
| Unit price | No | A price list or a person |
| Delivery date | No | A calendar and a person |
| Payment terms | No | A fixed template |
| VAT treatment | No | The business configuration |
| Open question | Yes, and this is its main job | Gaps in the meeting |
The layer that enforces this is not an instruction in text. OpenAI's structured-outputs documentation states that all fields in the schema must be specified as required, and that an optional parameter is emulated using a union type with null. That is exactly what is needed here: the model must return null in the price field rather than omit it. A missing field looks like a technical fault, while an explicit null is a statement that the information does not exist - and that is a statement you can check in code before anybody sees a screen.
How the draft becomes a quote, and who signs it off
In stages, each performed by a person whose name is stored:
- Review the open questions. Before anything else. If open questions remain there is no quote, there is a list of questions to send the client.
- Price the ready lines. From the price list or by an explicit human decision, never from the model's estimate.
- Unblock the blocked lines. Each is unblocked separately once the question that blocked it is answered, and the answer is stored on the record.
- Produce the document. The quote is built from priced lines only. The meeting transcript is not embedded in it in any form.
- Sign off. One named person, not a team. The draft is kept beside the quote that was sent so the difference can be displayed.
Stage four needs technical attention in Hebrew. A Hebrew quote is full of Latin system names inside Hebrew table cells, and that is exactly where text direction goes wrong in the conversion to PDF. Checking the produced document, not only the screen, belongs inside that stage rather than after it.
What happens when the client asks for a quote during the meeting itself?
This happens nearly every time, and it is the moment most scopes break. The answer is neither to refuse nor to give a number, but to hand over the draft itself:
- Read out the ready lines with the quantities that were stated, and no prices. It shows you were listening, and it is true.
- Read out the open questions aloud, in the room. A client who hears three precise questions immediately understands why there is no number yet.
- Set a date for the quote, not a date for thinking about it. A date agreed in the meeting is what prevents the second call asking what happened to the quote.
- If an order of magnitude is given verbally, it is given by a person, hedged out loud, and written into no automatically generated document. Once it is in writing it has become a price.
The common failure is running the model over the transcript that evening, getting a document that looks complete, and sending it the next morning. It will look professional, it will contain numbers nobody said, and the client will remember them precisely at the next meeting.
Related: digital signature and evidence on a quote, a manual price list against one source of truth, quality checks for Hebrew PDF generation.
What is stored, and why you keep what was rejected
The draft is not raw material to throw away after use. It is the evidence for why the quote looks the way it does:
- The draft as generated, before any person touched it.
- The quote as sent, as a separate document.
- The difference between the two, because it shows what the model habitually misses.
- The open questions and the answers received, with who answered and when.
- Rejected lines and the reason, so they do not resurface at the next meeting as if never discussed.
Sources
Frequently asked questions
May the model propose a price as a range only?
No. A range is a number the moment the client sees it, and it becomes a ceiling in the next conversation. If a client needs an order of magnitude before discovery is complete, that is something a person says in a conversation, not a field in an automatically generated document.
What do you do with a client who says just something basic?
Record the sentence as a quotation and emit an open question. Basic is not a scope, and it is the most common source of expectation gaps on small projects. The right open question is not what does basic mean, but which action must the user perform and how often.
How many open questions are too many?
There is no number, but there is a signal: if most lines are blocked, the meeting was an introduction rather than a discovery session. In that case the honest move is to say so and book another meeting, instead of sending a quote that papers over the gap with assumptions.
Should the transcript be attached to the quote as an appendix?
No. The quote is a commercial document, and the transcript is internal material with different sensitivity and a different access list. What does travel across is the approved summary, and only the parts that define scope - not what was said in passing.
Keep reading
Related service
Business Automation
I build custom automations that remove repetitive work end to end.
About the author
Yehonatan Saadia
Freelance automation, web & MVP developer
I'm Yehonatan Saadia, a senior developer who builds business automation, custom websites, and MVPs for small and mid-sized companies across the US, Europe, and Israel. These guides come from real client work, not theory.
Work with meHave a project like this?
Tell me what you're trying to automate or build. I reply within 24 business hours with a few targeted questions, then we walk through it on a free 30-minute call, with no commitment. You come away with a scope, a timeline and a fixed price - or a straight answer that it isn't worth building.