Asking for the right details

Every business has a short list of things it must know before it can help someone. A diagnostic centre needs to know whether the patient has fasted. A coaching institute needs the student’s class and which exam they are aiming at. A property broker needs a budget and an area. A photographer needs the date and roughly how many guests.

Your assistant can already have that conversation. What it could not do until now was record the answers as separate, named pieces of information — so they arrived as a paragraph of summary that a human had to read and retype.

A questionnaire fixes that. You describe the details you need once, and your assistant collects them in its own words, over as many turns as the conversation takes, then hands them back as tidy fields on the customer’s record.

Your assistant is not reading your questions out like a form. It knows what it needs and asks naturally, in whatever language the customer is using. If someone answers three things in one sentence, it takes all three.

Where to find it: open Bots (under Assistants), pick an assistant, click Open studio, and select the Tools tab. Scroll to Your Actions — what your assistant collects. If you have not used the Tools tab before, read What your assistant can do first.

The five-minute setup

1. Click New action.
2. Name it — lowercase, no spaces. collect_patient_details.
3. Description — when should the assistant use this? Write it for a new colleague: “Collect what the lab needs before booking a blood test.”
4. Fields to collect — the list of details. This is a JSON box; there is a worked example for your kind of business below, so copy the closest one.
5. Leave Ask the customer to confirm before submitting ticked.
6. Save.

That is a working questionnaire. The rest of this page is for when you want your assistant to choose between several of them, or you want to be more precise about what counts as an answer.

Step 1 — the fields

Each field has a name, a type, and whether it is required. A description is optional but worth writing — your assistant reads it to decide what it is actually asking for.

The four types

Type	Use it for	Example
string	words, names, anything free-form	"locality", "referring_doctor"
integer	whole numbers	"guest_count", "patient_age"
number	numbers with decimals	"marks_percentage", "budget_lakhs"
boolean	yes or no	"fasting_done", "has_parking"

A string field can also carry an enum — a fixed list of allowed answers. This is the single most useful thing on the page, and the next section is about when to use it.

The decision everyone gets wrong first: enum or free text?

Use an enum when you will later want to count, filter or report on the answer. Use free text when you only need a human to read it.

A property broker wants to know the locality. Written as free text, "locality" collects Whitefield, whitefield, Whitefiled, near Whitefield metro — four answers that are the same answer, and a report that cannot add them up. Written as an enum of the eight areas that broker actually covers, every answer is one of eight things.

But do not force an enum where the world is genuinely open. A clinic’s "referring_doctor" is free text — you cannot list every doctor in the city, and trying makes your assistant refuse a perfectly good answer.

A useful test: would I ever want a chart of this? If yes, enum. If it is context for the person who picks up the phone, free text.

An enum holds up to 50 options, each up to 40 characters. If you find yourself needing more, that is usually free text wearing a disguise.

What about dates?

There is deliberately no date type, and this catches people out.

Two reasons. First, your assistant already captures times the way people say them — “after Diwali”, “any evening next week”, “before my daughter’s admission” — and forcing that into a date picker loses the meaning. Second, booking an actual appointment is a different tool; a questionnaire is for working out what someone needs, not for putting something in the diary.

When the timing itself is what qualifies a lead, bucket it as an enum:

{"name": "event_timeline", "type": "string", "required": true,
 "enum": ["within_1_month", "1_to_3_months", "3_to_6_months", "just_exploring"],
 "description": "How soon the event is."}

That gives you something you can count, filter and act on — a photographer can treat within_1_month as urgent — which a free-text date never would.

Limits

At most 20 fields on one questionnaire. A description can run to 500 characters. If you are pushing 20, you probably have two questionnaires rather than one — see Applies to below.

Step 2 — worked examples

Real shapes from four different kinds of business. Copy the closest one and change the words.

A diagnostic centre

[
  {"name": "test_type", "type": "string", "required": true,
   "enum": ["blood_test", "scan", "health_package", "not_sure"],
   "description": "What the caller is asking about."},
  {"name": "patient_age", "type": "integer", "required": true,
   "description": "The patient's age in years."},
  {"name": "fasting_done", "type": "boolean", "required": false,
   "description": "Whether the patient has fasted, if the test needs it."},
  {"name": "home_collection", "type": "boolean", "required": false,
   "description": "True if they want a sample collected at home."},
  {"name": "referring_doctor", "type": "string", "required": false,
   "description": "The doctor who advised the test, if they name one."}
]

Note patient_age is required and referring_doctor is not. Required means your assistant will keep trying to get it before it can submit. Only mark something required if you genuinely cannot proceed without it — a required field the customer will not answer turns into a conversation that cannot end.

A coaching institute

[
  {"name": "student_class", "type": "string", "required": true,
   "enum": ["class_9", "class_10", "class_11", "class_12", "repeater"],
   "description": "Which class the student is in now."},
  {"name": "target_exam", "type": "string", "required": true,
   "enum": ["neet", "jee_main", "jee_advanced", "board_only", "undecided"],
   "description": "What they are preparing for."},
  {"name": "marks_percentage", "type": "number", "required": false,
   "description": "Their most recent percentage, if they share it."},
  {"name": "caller_is_parent", "type": "boolean", "required": false,
   "description": "True if a parent is calling rather than the student."}
]

undecided and not_sure in these lists are doing real work. Without them, your assistant has to force a caller into a box they do not fit, or leave a required field empty and get stuck.

A property brokerage

[
  {"name": "purpose", "type": "string", "required": true,
   "enum": ["buy", "rent", "sell", "just_looking"],
   "description": "What the caller wants to do."},
  {"name": "budget_lakhs", "type": "number", "required": true,
   "description": "Their budget in lakhs."},
  {"name": "bhk", "type": "integer", "required": false,
   "description": "How many bedrooms."},
  {"name": "locality", "type": "string", "required": false,
   "enum": ["whitefield", "indiranagar", "koramangala", "hsr", "sarjapur", "other"],
   "description": "Which area they are looking in."},
  {"name": "possession_timeline", "type": "string", "required": false,
   "enum": ["ready_to_move", "within_6_months", "under_construction"],
   "description": "How soon they need it."}
]

other on the locality list matters. Without it a caller looking somewhere you do not cover cannot be recorded at all — and knowing that people keep asking for an area you do not serve is worth having.

A wedding photographer

[
  {"name": "event_type", "type": "string", "required": true,
   "enum": ["wedding", "engagement", "pre_wedding_shoot", "reception", "other"],
   "description": "What the shoot is for."},
  {"name": "event_timeline", "type": "string", "required": true,
   "enum": ["within_1_month", "1_to_3_months", "3_to_6_months", "just_exploring"],
   "description": "How soon the event is."},
  {"name": "guest_count", "type": "integer", "required": false,
   "description": "Roughly how many guests."},
  {"name": "venue_city", "type": "string", "required": false,
   "description": "Where the event is happening."}
]

Step 3 — telling your assistant which questionnaire to use

Once you have more than one, your assistant needs to know which is which. That is what Applies to is for.

A detailing studio with a coating questionnaire and a seat-cover questionnaire fills in SKUs CERAMIC-* on the first and SEATCOVER-* on the second. The * at the end matches any SKU starting that way, so you do not list all nine coating packages.

You can also narrow by Kinds (product, service, package) or by Categories, which is free text matching how you describe your offerings.

Leave Applies to empty and the questionnaire is available whenever your assistant judges it relevant from the description alone. For a business with one questionnaire, that is the right answer — do not fill this in for the sake of it.

Each list holds up to 40 entries of up to 120 characters.

This guides your assistant; it does not force it. The assistant still chooses, the way a good receptionist would. If it consistently picks the wrong one, the fix is usually a clearer Description, not more entries here.

Step 4 — confirmation, and going live

Ask the customer to confirm before submitting is ticked by default and should usually stay that way. It makes your assistant read the details back and get a clear yes before recording anything. Untick it only for questionnaires where nothing happens as a result — a preference you are noting, not a booking you are taking.

Which bot? Leave blank and every assistant can use it. Name one and only that assistant gets it, which is what you want when a support line and a sales line need different questions.

Live controls whether the questionnaire is in use. Unticking it pauses the questionnaire without deleting it — useful for a seasonal offer. Your assistant stops offering it straight away — the change reaches every assistant, on every channel, as soon as you save.

Every save makes a new version, and you can roll back to an earlier one from the version list. Rolling back creates a new version with the old content rather than erasing history.

Beyond the type: real limits on an answer

Type and enum aren’t the only checks you can put on a field. A number can have a sensible range, text can have a sensible length, and a handful of common shapes — an email, a phone number, a pattern you describe yourself — can be checked properly rather than just collected on trust. See Checking the answers you collect for all of it, including which of these are a hard stop and which are only ever advice.

What is not built yet

Two things you may look for and not find. Both are honest gaps rather than hidden settings.

“Require this before” appears in the editor with (not enforced yet — coming soon) next to it. You can record the intent — do not quote before this questionnaire is answered — and your assistant will not yet be prevented from quoting. Until it is, treat it as a note to yourself.

Checking an answer against your own system. Everything on this page and on Checking the answers you collect runs entirely inside Kooday, against rules you typed in — a range, a shape, a pattern. Handing an answer to your own database, your CRM or your booking software, and asking “is this actually a valid order number?” or “is this customer already in our system?”, is designed but not yet built. For now, a value only your own records could confirm cannot be verified at intake — your assistant will collect it and pass it on for a person to check afterwards.

Troubleshooting

My assistant is not asking these questions

1. Check the questionnaire is Live.
2. Check Which bot? — if it names a different assistant, this one never sees it.
3. Read your Description aloud. It is what your assistant uses to decide whether this questionnaire is relevant at all. “Collect details” tells it nothing; “Collect what the lab needs before booking a blood test” tells it when.
4. If you set Applies to, try clearing it temporarily. A SKU prefix that matches nothing you actually sell will keep the questionnaire hidden.

It asks, but the conversation never finishes

Usually a required field the customer will not or cannot answer. Your assistant cannot submit without it, so it keeps asking. Make it optional, or add an escape value to the enum — not_sure, undecided, other.

The answers come back in the wrong field

Two fields whose descriptions sound alike. "name" and "patient_name" on the same questionnaire will be confused; "caller_name" and "patient_name" with descriptions saying who is calling and who the test is for will not.

I get invalid_fields when testing

The details did not match what you declared — usually a number field being given words, or an answer outside your enum list. The message names the field. If it names one you expect people to answer loosely, that field probably wants to be free text rather than an enum.

A sensible first configuration

One questionnaire, five fields, no Applies to, confirmation on:

[
  {"name": "enquiry_type", "type": "string", "required": true,
   "enum": ["new_customer", "existing_customer", "complaint", "other"],
   "description": "What kind of enquiry this is."},
  {"name": "what_they_need", "type": "string", "required": true,
   "description": "What the customer is asking for, in their words."},
  {"name": "timeline", "type": "string", "required": false,
   "enum": ["urgent", "this_week", "this_month", "just_exploring"],
   "description": "How soon they need it."},
  {"name": "budget_known", "type": "boolean", "required": false,
   "description": "True if they have a budget in mind."},
  {"name": "location", "type": "string", "required": false,
   "description": "Where they are."}
]

This works for almost any business on day one, and it teaches you the thing worth learning: which of these your team actually uses. Add fields when you find yourself wishing you had asked. Do not start with twenty.