Summary: An AWS Machine Learning Blog walkthrough published September 10, 2026 uses Amazon Quick Automate and Amazon S3 to turn multi-tab RFI questionnaires into structured CSV records. The pattern extracts main and subquestions with inherited parent context, outputs four defined columns, and adapts to new formats by changing natural-language instructions, though validation remains pre-production. Irregular numbering, merged cells, metadata outside column headers can require refinement or make the approach unsuitable, and the post does not explain ambiguous question hierarchies.
An RFI questionnaire usually gets filed under writing work. It is a parsing job. What arrives is a workbook with several tabs, question sets nested in a hierarchy, category metadata, and a mix of response types, and somebody has to turn all of it into something the teams downstream can use. On September 10, 2026, the AWS Machine Learning Blog published a walkthrough that automates that step end to end with Amazon Quick Automate.
The workflow, step by step
The pattern is narrow, and it is worth understanding before you copy it. A multi-tab RFI workbook sits in Amazon S3. Quick Automate reads it, extracts and structures the questionnaire data, and writes a clean CSV back to S3. The AWS post states the pain without dressing it up: hundreds of questionnaires a year, each one a complex workbook, and any format change dragging everyone back into manual rework.
Quick Automate is described as multi-agent automation for enterprise processes spanning departments, systems, UI and API interactions, and third-party systems. You set out processing goals in plain language, and it hands back an executable workflow covering ingestion, transformation, validation, and output. You refine it conversationally, run it against your data, and promote validated versions across AWS Regions.
Setup is plumbing work
Three things must exist before anyone writes a prompt. An Amazon Quick Enterprise subscription with Quick Automate access. An S3 bucket in the same AWS Region as the Quick application. And an IAM role that lets Quick Automate read from and write to that bucket.
In the walkthrough, the role is created with a custom trust policy for quicksight.amazonaws.com and given permissions for s3:GetObject, s3:PutObject, and s3:ListBucket. Its ARN gets pasted into an S3 action connector in the Quick console, and that connector is shared with an automation group. Under that group the project is created, with an optional business case section for tracking hours saved and target launch dates.
Anyone who has wired up connectors before will recognize all of this. What matters is the next part.
Plain language stands in for parsing code
The prompt in the AWS example names the connector, the file, the prefix, the sheet, and the output shape. Numbering and indentation identify main questions and subquestions, category metadata comes from column headers, and the columns are Serial Number, Category, Question, and Response Type. What gets generated maps straight onto those instructions: read data, extract and transform, structure output.
That last step is the one to watch if you have done this by hand. Subquestions become standalone records once parent context is merged into them. Inside a spreadsheet, a subquestion alone means nothing. In a flat CSV it has to carry that meaning itself.
This sits in the same family of problems as choosing a structured data extraction tool for AI agents: the model call is seldom the hard part. What is hard is settling what counts as a record and keeping enough context attached that it still makes sense once it leaves its original layout.
Where the approach stops working
The AWS post is explicit that common scenarios work without custom code. That qualifier carries real weight. Workbooks with irregular numbering, merged cells, or category metadata living somewhere other than column headers may leave the generated workflow needing refinement, or may not suit it at all.
How the approach adapts also deserves a careful read. New questionnaire formats, the post says, are handled by updating the natural-language instructions. That is a real departure from maintaining a parser, but it is not free. Somebody still has to notice the format changed and rewrite the instructions, and validation still runs in a pre-production account before promotion.
The supplied material does not say how the workflow handles conflicting or ambiguous question hierarchies, or what happens when a sheet departs from the structure the prompt describes. If your workbooks are messy in ways the example is not, test that before you commit.
How to start small
Take one questionnaire format you handle repeatedly. Build the connector, describe the extraction in plain language, and check whether the generated records would pass your downstream team’s bar without cleanup. If they would, the Import/Export promotion path moves it into production without a rebuild.
If they would not, an afternoon bought you something worth knowing about your own data.