A request arrives. Here is what the system reads, what it checks, what it decides, what it drafts, where you approve, what it does when it can't tell, and what the record looks like afterward. There's a checklist at the bottom you can work through on your own build.
The example below is illustrative. I wrote it. It isn't anyone's real intake and the details aren't a client's. The shape is the part worth copying.
Say you take inbound work through a form on your site. On a Tuesday evening one comes in, and twenty minutes later the same person emails you directly with the context they didn't want to type into a box.
A website form at 8:14pm, then an email from the same address at 8:33pm referring to it.
Name, company, email, phone, a free-text box, and a dropdown for what they need.
Three paragraphs of context, a date they need it by, a number they've budgeted, and the name of a second company that's involved.
The dropdown is still on its default value. The phone number has nine digits. The free-text box says "see email."
That is a completely ordinary inbound request, and it is already too messy for a rule that only reads the form.
Two messages, one request. The first job is deciding that. The workflow matches the email address and the timestamp against recent submissions, finds the form entry from nineteen minutes earlier, and joins them into a single record instead of creating a second one.
Then it reads. It pulls the facts the form didn't collect out of the email body: the deadline, the budget figure, the second company. It checks your CRM for that address, that domain, and that company name, and attaches the existing record if there is one. Every fact it extracts keeps a pointer back to the sentence it came from.
It has joined the messages and extracted the facts. It has not decided whether to accept the work. Reading and deciding stay separate steps, so when a reply goes wrong you know which one broke.
The checks run next, and each one records what it looked at and what it found.
Every one of those results goes on the review screen later, with its evidence. A reviewer who has to go re-derive a check has been handed a chore, not a draft.
The decision is which draft to prepare and who owns it, and nothing beyond that. Your rules, written down in advance, in language that reads like rules:
The system does not decide whether to take the work, what to quote, or what to promise. If you can't write the rule down in a sentence, it isn't a rule yet, and the workflow shouldn't be guessing at it.
Four things get prepared, and all four sit in a queue.
Nothing has left the building. That's the state the system is designed to reach, and then it waits.
On the review screen: the original messages, what each check found and where the facts came from, the draft, and the rule that produced it. You have three verdicts.
Approve. It sends and writes the record.
Edit, then approve. Your version sends, and the difference between what was drafted and what you sent gets recorded.
Kill. It stops, and it asks you why in one line, so the answer can turn into a rule later.
The gate has no side door. If there's any path where the system sends without you, you don't have an approval gate.
Time the review. If it takes longer than writing the reply, inspect the evidence, draft quality, and review process before expanding the workflow.
Define what happens when the request, the rules, or a source cannot be trusted.
On any of those it stops, writes down what it knows and what it couldn't resolve, and puts it in front of a person with the original message attached. It doesn't send a vague reply to cover the gap. A hedged reply to a customer is worse than a slow one.
Count exceptions and read them weekly. Review the repeated reasons, and check whether rule changes reduce those cases without hiding failures.
Six weeks later somebody asks what happened to that Tuesday request. The record should answer without anyone having to remember.
Both original messages, joined, with their timestamps and channel.
Each check, what it looked at, and what it returned, including the ones that passed.
The draft as generated, the version that sent, and the difference between them.
Who approved it and when, or who killed it and the reason they gave.
The disposition, the next action, the owner, and the date it's due.
Keep those records so someone can investigate a wrong reply.
You don't need me for the first one, and a rough version that stops at the gate beats a perfect one that sends. Work down this list in order.
Read the hours-saved math guide before you write down what step 12 was worth.
If you want this built against your systems and your rules rather than assembled by hand, that's the Lead Response & Qualification Engine, which is this workflow with your intake sources, your qualification criteria, and your approvers wired into it.
Either way, the next thing to do is the boring one: open a spreadsheet, take the last 50 requests, and write down what actually happened to each. Review them to see which steps need a closer measurement.
Describe how requests reach you today. The written assessment comes back with where the gate belongs and what to build first.