Write a SQL Query From a Business Question

This prompt translates a plain-English business question into a runnable, well-formatted SQL query grounded in your actual schema. You give it the database flavor and your table definitions so it uses the correct dialect and real column names instead of inventing them. The request for inline comments and an explicit list of assumptions is what makes it safe to use: you can audit the logic and catch any guesses the model made about joins or business rules before you run it on production data.

What you can expect back

SELECT
  -- Truncate order timestamp to the first day of its month
  DATE_TRUNC(DATE(o.created_at), MONTH) AS order_month,
  -- total_cents stored as integer cents; convert to dollars
  SUM(o.total_cents) / 100 AS revenue_usd
FROM orders AS o
JOIN customers AS c
  ON o.customer_id = c.id
WHERE
  -- Only customers who signed up during calendar year 2025
  c.signup_date BETWEEN '2025-01-01' AND '2025-12-31'
  -- Assuming 'completed' is the status for fulfilled orders
  AND o.status = 'completed'
GROUP BY order_month
ORDER BY order_month;

Assumptions:
- 'Revenue' counts only orders with status = 'completed'.
- total_cents is in cents; divided by 100 for dollars.
- Customer signup year is based on signup_date, not first order date.

Illustrative example — your results will vary by tool and inputs.

Get sharper results

• 01Always paste real column names and types rather than describing tables in prose, because the model can only avoid hallucinated fields if it sees the actual schema.
• 02Read the 'assumptions' section first and confirm each one, since a wrong guess about a status value or join key produces a query that runs but returns wrong numbers.
• 03If a metric is ambiguous (revenue gross vs. net, active users by login vs. order), define it inside the business question so the model doesn't have to guess.
• 04Ask it to add a LIMIT 100 and run the query as a sanity check before removing the limit for the full aggregation.
• 05For expensive engines like BigQuery, request that it select only needed columns and filter on partitioned date fields to keep scan cost down.

Adapt it for your case