How to get a client to fill in a questionnaire or approve something your AI built

A lot of client work waits on one person answering. The client has to fill in the brand questionnaire. Confirm the scope. Pick one of three directions. Say yes to the draft.

Your agent can write the page for any of these in a minute. Getting it in front of the client is the hard part. A page on your laptop is no use to them. A public link means anyone with the address can read their answers. And once they've answered, the answers are somewhere your agent can't see, so you copy them back by hand.

This article is about that gap. We make Spryloom, and the last option below is ours. The others are real choices, described as fairly as we can.

What the job actually needs

Before comparing options, it's worth being exact. Collecting a client's input needs four things:

1. A way in for someone outside your team. The client shouldn't have to create an account on a tool they've never heard of. An email address and a link is about the limit of what you can ask.
2. Privacy between clients. One client must never see another's answers. Only you, as the owner, should see everything.
3. A record of who answered and when. "The client approved" is useless without which person, and when. And people shouldn't type their own names: anyone can type anyone's.
4. The answers back in your work. If you have to copy them out of another tool, the agent that could draft the brief from them can't.

Option 1: a form tool

Google Forms, Typeform, Jotform and similar tools are the honest default. Clients have seen them before, they're free or cheap, and the forms look polished.

Where it strains: the answers live in the form tool, so someone has to export or paste them before your agent can use them. The form is the form tool's shape, so a questionnaire that changes depending on earlier answers, or that shows the client a draft to react to, is awkward. And an approval is usually a second tool or an email reply.

Option 2: a client portal

Tools such as HoneyBook, Dubsado and Notion-based portals bundle forms, contracts, invoices and a place for the client to log in. If you want all of that together, one of these is a reasonable choice, and the contract and payment parts are things a plain page doesn't do (see below).

The costs are a monthly fee per account and a shape you adopt. The portal has its own idea of a client, a project and a form, and your agent works through exports, not directly with the data.

Option 3: a document and an email

Send a Google Doc or a PDF and ask the client to reply. It needs no setup and everybody can do it. The answers arrive as prose, scattered across replies, and "did they approve?" means searching an inbox. Fine for one client and one question.

Option 4: ask your agent for an app

An agent can build the whole thing: a server, a database, sign-in, the exact questionnaire you wanted. Getting it to a client is where the work is: hosting, a database, a login that is actually secure, and somewhere to keep it running. That's the right amount of machinery for something with rules and schedules. For a questionnaire it's more than you need.

Option 5: a page the client answers

This is what we built. Your agent writes the page, as before, and declares the lists it keeps in a small manifest. Spryloom keeps the lists, puts sign-in in front, and stamps every record with who saved it. There's no server and no database to set up.

Here is one, from the first ask to the approval.

Ask

Dana is a brand consultant. A new client, Chris, runs a bakery and needs a brand brief. In Claude Code, Dana asks: "Make a questionnaire for Chris about his bakery's brand. Ask what he wants customers to feel, who his customers are, and three brands he likes. I'll invite him." The agent writes the page and declares two lists:

runtime:
  frontend: static
  backend: none
data:
  lists:
    answers: own
    decisions: own

own means each person sees only what they saved, and the page's owner sees everything. That is the right setting here: Chris sees his own answers, nobody else can, and Dana sees them all. The other kind, shared, shows every record to everyone who can open the page, which suits a team checklist (an example).

Publish and invite

The agent publishes it. It's live in seconds at a private address, and Dana invites Chris by his email address. Chris gets a link, signs in with his email, and sees the questionnaire. He has no account to create (how invites work).

The page's own script saves and reads at /~data, on the page's address:

await fetch('/~data/answers', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json', 'Spryloom-Request': 'data' },
  body: JSON.stringify({ question: 'Three brands you like', answer: 'Patagonia, Aesop, Mailchimp' }),
});
const { records } = await (await fetch('/~data/answers')).json();

Know who answered

Chris doesn't type his name. Spryloom stamps each record with his email and the time, from his sign-in, so the page can't get it wrong and nobody can answer as someone else. Only the person who saved a record, or the page's owner and admins, can change or delete it.

Read the answers back

When Chris tells Dana he's done, she asks her agent: "What did Chris say about his customers? Draft a one-page brand brief." The agent reads the page's records as Dana, and sees exactly what she would see in the page. From a terminal, spry data shows a page's lists, and spry data export saves every record as JSON and CSV.

The agent drafts the brief from what Chris wrote, not from what Dana remembers of a call.

Ask for a decision

Dana publishes the draft as a second page: the brief, and two buttons, Approve and Request changes. Each saves a record to the decisions list, with Chris's email and the time. Dana invites him. Chris reads the brief and clicks. Next to the date, the record says who clicked.

Grow

A month later Dana wants something a list can't do: "Email Chris on Friday if he hasn't answered." That needs a schedule and a server, so the agent adds one (how a reminder works), and the next publish makes the page an app, at the same address, with the same people. Every record moves into a table in the app's own database. Chris signs in again with nothing to redo.

Three more

• Client intake. One own list. A new client gives their details, goals and access needs. Dana's agent reads them to start the project plan.
• Scope confirmation. One own list. The page shows the agreed scope and a Confirm button. The record says who confirmed and when, which settles "I thought that was included".
• Pick a direction. One own list. The agent shows three options and the client picks one. The choice goes straight into the next prompt.

What stays safe

• Only people you invite can open the page, and each signs in with their email before the page is sent.
• With own, one client can't read another's answers. Only the page's owner sees every record, so one page per client is the simplest way to keep clients apart.
• The page's scripts can save to its own lists and can't send data anywhere else.
• Each page's records are walled off from every other page's in the database itself, not just in code.
• Requests to save are accepted only from the page itself, not from another site a person happens to have open.
• Every export, and every time an agent reads the data, is written to the page's access log.

What it doesn't do

A page that saves data keeps lists. It doesn't run anything on its own:

• No notification when the client finishes. Dana finds out when Chris tells her, or when she asks her agent to check. Telling her automatically needs an app, with email.
• No contract signing and no payments. An Approve record is a stamped record with an email and a time. It isn't an electronic signature, and it doesn't take money. If you need either, a client portal or a signing tool does that part.
• No schedules and no reminders. "Chase Chris on Friday" needs an app.
• No calls to outside services. Posting to Slack or asking an AI model from the page is an app's job.

In each case the way forward is the same: your agent adds a server, and the next publish makes it an app with every record moved in.

Try it

Add Spryloom to Claude Code, Codex or Cursor (how), then ask your agent for the page you keep wishing a client would fill in:

Make a questionnaire for my new client about their brand: what they want customers to feel, who their customers are, and three brands they like. Publish it with Spryloom and invite them by email.

The agent picks a page that saves data when a list is all it needs, and tells you why. More on how saving works is in the guide.