Module 4 — Communication · Lesson 4.4
Requests and Intake
Publishing a public request page, collecting submissions, and converting them into work
~10 min
What you'll learn
- Create a request page and customize its fields
- Share the public link with people who have no Kavanah account
- Convert a submission into a task without losing its context
- Design intake fields that make triage fast rather than slow
Every team that serves other people has an intake problem: requests arrive by email, in chat, in corridors, and none of them arrive in a form you can queue. Requests is the fix — one link, one form, one queue — and the quality of the form decides whether the queue is a relief or a second inbox.
Creating a request page
Open Requests under the Inbox group and create a request page. Customize its form fields to ask for what you actually need to start work.
The page is public and tokenized: the link is the credential. Anyone with it can submit, and they need no Kavanah account. That is the point — it is for clients, other departments, and people who will never log in.
Share the link wherever requests currently arrive. If your team gets work by email, put the link in your signature and in your auto-reply. If it arrives in a Slack channel, pin it there.
Designing the form
The temptation is to ask for everything. Resist it: every field you add is a field a requester can get wrong, and a long form gets abandoned in favour of the email they were going to send anyway.
Ask for the minimum that lets you decide. In practice that is usually four things: what they want, why it matters or by when, who to talk to, and enough identifying detail to know which client or system it concerns.
One principle carries most of the value: ask for the thing that would otherwise generate a round-trip. If every intake conversation starts with 'which environment?' or 'which account?', that is a field. If you have never once needed it, it is not.
And prefer structured fields over free text for anything you will route or filter by, for the same reason it matters on tasks: free text produces four spellings of the same value.
Working the queue
Submissions land in Requests for review. You read them and convert the real ones into tasks.
Convert rather than retype. The conversion carries the submission's context onto the task, which matters when the person who does the work is not the person who triaged it — the original wording is often the only record of what was actually asked for.
Work the queue on a cadence, and say what the cadence is on the form. 'We look at these every weekday morning' sets an expectation you can meet; silence sets an expectation you cannot. An intake queue's reputation is made in the first month and is very hard to change afterwards.
How this relates to triage
Requests and Triage are both queues in front of the board and they are not the same thing.
Requests is intake from OUTSIDE: people who are not in your workspace, submitting through a form. The queue is authoritative — a submission is a real request from a real person, and the decision is what to do about it, not whether it is real.
Triage is the AI-captured candidate queue from INSIDE: statements in conversations that looked like commitments. The decision there includes whether it is work at all.
Different queues, different questions, and it is worth having different people own them if you have the people — the skills are genuinely different.
Set up intake
- 1
Create a request page with four fields
What, why or when, who to contact, and one identifying field. Add more only when a missing field actually costs you a round-trip.
- 2
Put the link where requests currently arrive
Email signature, auto-reply, the Slack channel people ask in. Intake only works if it displaces the existing path.
- 3
State your review cadence on the form
An expectation you can meet. This is what stops people also emailing you 'just in case'.
- 4
Convert a submission into a task
Convert rather than retype, so the original wording travels with the work.
What to watch
- Time to first response
- How long a submission waits before anyone acts on it.
- Healthy signal: Inside your stated cadence, consistently. Missing your own stated cadence is worse than not stating one.
- Round-trip rate
- Share of submissions that need a clarifying question before they can be triaged.
- Healthy signal: Falling. A high rate is a form-design problem, and the fix is usually one more structured field.
- Bypass rate
- How much work still arrives by email or chat instead of through the form.
- Healthy signal: Falling towards zero. If people keep bypassing it, either they do not have the link or the form is too long.
Key takeaways
- ·A request page is public and tokenized — the link is the credential, and no account is needed.
- ·Ask for the minimum that lets you decide; every extra field trades completion rate for detail.
- ·Convert submissions rather than retyping so the original wording travels with the task.
- ·State your review cadence on the form, then meet it.
- ·Requests is outside intake; Triage is inside capture — different queues, different questions.
Next: broadcasting outward inside the workspace — announcements, and the Comms surface.