Ask for data, not documents

The first design decision is about the input, and it is the one most often got wrong. The obvious build reads the enquiry email with a model and extracts the company, the product and the quantity. It works, most of the time, and it is a patch over a problem the business created itself: the prospect had those three facts as data and turned them into prose because the website gave them nothing better.

Decision: a short form. The prospect answers five questions: company, range, quantity, timeframe, and anything else. The answers arrive as named fields. Every later step reads them by name and nothing has to guess. The model is saved for a step that needs reasoning, not for undoing an email.

Why this matters on this platform in particular. Files a participant uploads are stored and can be shown to a person, but they cannot be handed to a model today. A workflow that depended on reading a forwarded PDF would have nowhere to go. Asking for data is the better design anyway; here it is also the only one that runs.

What the agent wrote. A Workflow group with the form surface, five Input nodes inside it with validation rules, a Code step that reshapes the answers into a record, and a Message that shows the record back. One participant, on the widget. No model at all yet.