Collect work from clients without email ping-pong

The default way work arrives is an email that says "quick favour". It has no deadline, no scope, no priority and no record. Somebody reads it, means to action it, and it slides off the bottom of the inbox.

The fix is not a better inbox. It is making the front door structured.

The three doors

Work arrives three ways. Handle all three or people will route around you.

1. A form. A public link anyone can fill without an account. This is the main door, and the only one where you control the fields.

2. Email. People will email regardless. An address like requests@ that turns inbound mail into records — with attachments preserved — means those requests join the queue instead of living in one person's inbox.

3. Manual entry. Someone mentions it in a corridor or on a call. There must be a fast way to create the record yourself, or the corridor requests stay invisible.

If only the form exists, the other two become shadow queues and your data is wrong about how much work you actually receive.

The model

Requests — the intake record. Requester name, requester email, client relation, type, title, description, priority, requested-by date, attachments, status, assignee.

Clients — who is asking. Linked from requests so you get history per client.

Request types — the categories, as a table rather than a select field, because each type carries configuration: which questions to ask, who it routes to, the target turnaround.

Comments / updates — the thread on a request. Keeps the conversation attached to the work rather than in email.

Making request types a table rather than a dropdown is what lets you set different SLAs and different owners per type without a rule engine.

Designing the form

The form is the whole leverage point. Every field you ask for is a field you never have to chase — and every field you ask for reduces completion.

Ask only what changes what you do:

• What do you need? (type — drives routing)
• Describe it. (one open field, with a placeholder showing a good example)
• When do you need it by? (date — not "urgent/not urgent", which is always urgent)
• What happens if it is late? (this one question does more prioritisation work than any priority dropdown)
• Attachments.

Use conditional questions. A design request needs dimensions and brand guidelines. A data request needs a date range and a format. Asking everyone every question guarantees an abandoned form. Show the follow-up questions only when the type is selected.

Do not ask for a priority. Everyone picks high. Ask for the date and the consequence, and derive priority yourself.

Turnaround, computed not promised

Give each request type a target turnaround in days. Then:

• Target date — formula: created date + the type's turnaround.
• At risk — flag when target date is within 2 days and status is not Done.
• Breached — target date passed, still open.

Now you can report honestly on whether you hit your own targets, by type and by client. That number is uncomfortable the first month and extremely useful thereafter — it is the evidence for either hiring, or for renegotiating what you promise.

Closing the loop

The reason people revert to email is that a form feels like shouting into a void. Fix that explicitly:

1. Immediate acknowledgement on submission, with the reference number and the target date. Automatic.
2. A status update on assignment — someone specific now owns this.
3. A notification on completion, with whatever was produced attached.

Three automated emails. They are the entire difference between an intake process people use and one they bypass.

If your tool supports it, give each requester a link to view their own request's status. Most "any update?" emails exist because there is no way to check.

The views

• Triage — new requests, unassigned, oldest first. Someone owns this view every morning.
• My queue — assigned to me, not done, sorted by target date.
• At risk — target date within 2 days, not done. The daily standup list.
• Breached — the accountability view. Review weekly, not to blame but to find the pattern.
• By client — one client's requests, open and historical. Invaluable before a renewal conversation.
• Volume by type — grouped count over time. This is your case for more people, or for a self-service fix.

That last one earns its keep. If 40% of requests are the same question, the answer is documentation or a self-service tool, not more capacity. You cannot see that pattern in an inbox.

Automations

1. Request created → acknowledge the requester, with reference and target date.
2. Route by type — assign to the right person or team automatically.
3. Status → In progress → notify the requester who owns it.
4. At risk → notify the assignee. Once.
5. Status → Done → notify the requester with the output attached.

Deliberately not automated: closing stale requests. An automatic close on a request someone is still waiting for is worse than no process at all.

Where intake goes wrong

Too many fields. Completion falls, people email instead, and you are back where you started with an extra form nobody uses.

No acknowledgement. The void problem. This is the single most common reason intake processes fail.

Priority as a dropdown. Everything is high priority. Derive it from dates and consequences.

No email door. People email anyway. Without an email route, those requests are invisible and your volume data understates reality — usually by a lot.

Treating it as a ticket system when it is project work. If a request routinely spawns a week of work, the request should create a project, not become one. Keep intake as the front door and hand off to a project tracker.

Start here

One table (Requests), one form, three automated emails. An hour of work.

Add clients when you need history per account. Add request types when routing by hand gets tedious. Add SLA computation when someone asks how long things take and you cannot answer.

The measure of success is simple: after a month, what proportion of incoming work arrived through the front door rather than a direct message? If it is not rising, the form is asking too much or the acknowledgements are not landing.