Suppose a service company receives project inquiries through forms and email. Some explain the business need clearly. Others contain a few sentences and an attachment. A staff member reads each request, gathers missing information, and prepares a brief for the person who will respond.
This is a hypothetical design case, not a report of a client engagement or measured results.
Give the assistant a preparation job
The first version would collect the authorized inquiry material and propose a structured brief: requested outcome, relevant systems, stated constraints, unanswered questions, and links back to the original material. Anything not present would remain unknown.
The assistant should not invent a budget range because a similar project had one. It should not treat an aspirational date as an agreed deadline. A useful brief preserves the difference between what the prospect said and what the company still needs to establish.
A staff member reviews the brief before it becomes the basis for an external response. Existing rules can route it to the appropriate team. An ambiguous request goes to a shared review queue rather than being silently rejected.
Keep the first release narrow
A sensible pilot would leave pricing, scheduling commitments, and proposal sending outside the assistant's authority. It would also limit access to the inquiry, rather than handing over the entire customer database just in case.
Test the workflow against ordinary requests and difficult ones: duplicate submissions, contradictory dates, unsupported file types, and messages containing unrelated instructions. The goal is not a beautiful summary of the easiest example. It is predictable handling of the cases that consume staff attention.
Decide what would justify keeping it
Measure time spent preparing and correcting briefs, missing details discovered during review, and whether the recipient can act without rereading everything. Count the review work, not just generation time. Track mistaken routing separately from harmless wording edits.
If the brief makes the next conversation better, the pilot has a reason to continue. If it merely adds another document to read, improve the process before expanding the automation. The business case depends on useful preparation, not on how many summaries the system can produce.