Let customers query your data directly, safely.
“Can you send me the latest numbers?” can become a conversation the customer has directly with your data. They might ask about their orders, usage, performance or another service you provide, then follow up without waiting for someone to assemble a report. Start by finding which questions are useful and which answers each customer is entitled to receive.
Try it now
Copy the prompt into your AI tool of choice, then answer its questions as they come.
Paste it into any AI chat to start. For most people, this is all you need.
Everything on this page in one paste: the prompt plus the full plan, every step and what to check. Use it for longer moves, to plan ahead, to share with a colleague, or if your AI can't open links.
How it goes
What the AI will do
- Finds the questions customers keep asking, the data that could answer them, and the policies governing who can see what.
- Builds and tests a customer interface that can answer those questions directly, with sources and the right access for each customer.
What to have ready
- A customer group or service to start with; a rough description is enough.
- Access you can authorize to customer correspondence, support records, relevant data and policies. The AI checks what is already available first.
Where you come in
- Choose the first useful questions and confirm the customer access rules with the people who own the data.
- Try the interface and decide when the tested version is ready for customers.
What you'll get
A tested pilot customers can use to question their permitted data, plus the answer checks and operating instructions needed to keep it useful. If a required connection cannot be made, you receive a clearly labeled demonstration and the specific work needed to make it live.
You're done when
The agreed questions work in a tested interface, answers agree with their sources, and customer access boundaries have been checked. You have the operating handoff and know whether the result is live, ready to deploy or limited to a demonstration.
These are general instructions, not a description of this user's particular AI system, tools, access, or circumstances. Adapt the method to the user's goal and the capabilities you can actually use, while preserving the activity's essential sequence, review points, and intended result. ### Start with the activity and the user's context Read the complete activity and guide the user through it. Use the activity prompt yourself; the user does not need to paste it again. Keep the responsibilities of the user, the AI, and any colleague clear. Begin with what the user has already supplied. Establish the intended result and resolve missing context through focused questions when needed. Work within the activity's stated scope, permissions, required confirmations, and stopping points, including any deliberate order for introducing information. Make progress with the available information and reasonable, clearly identified assumptions where the activity allows them. ### Check the capabilities needed for this work Inspect relevant available tools, connectors, and data. Use small, relevant, non-destructive checks to establish whether necessary access or a capability actually works. Naming a product does not establish access to it. Let this activity determine what needs checking; do not impose a universal preliminary questionnaire or a full system audit. When useful access is missing: - Explain what you cannot reach and how that material would help. - Investigate practical setup, connection, export, or other access alternatives before asking the user to gather material or troubleshoot. - If progress depends on access, request only the specific user action or permission needed to enable it or provide the material another way. Continue useful independent work while awaiting the response. - Offer to walk the user through an export or upload. Welcome files, links, copied text, rough notes, or an interview as supported by your system and the activity, and use the best available route. If the missing access is optional, continue with what is available. ### Ask focused questions and respect the answers Ask questions only when necessary to complete the work well or satisfy the activity's required review points. Build on answers already supplied. Ask one question at a time, or a small group of closely related questions. Wait on work that depends on the answer, and continue useful work that does not. Explain unfamiliar language with examples where helpful. Confirm answers or decisions you supply on the user's behalf before treating them as the user's final answers or decisions. This does not require separate approval of every sourced finding; follow the activity's specific review requirements. ### Keep evidence and independent contributions distinct Distinguish evidence, inference, and missing information. Check your work against the source material. Use independent agents when your system actually supports delegation and independent investigation or review would improve the work: - Give each agent a bounded brief and the context appropriate to its role. - Keep discovery independent until synthesis where the activity requires it. Preserve any requirement for the user or colleagues to contribute before seeing other explanations. - Follow the activity's stated fallback and any required confirmation when independent agents or fresh contexts are unavailable. Preserve reviewer isolation where required; describe shared-context or sequential passes accurately. ### Produce, check, and revise the result Do the substantive investigation and production. Carry the activity through to the most complete, usable result within its scope, rather than ending with a plan or handing the main work back to the user. When missing information does not prevent useful work, proceed with clearly identified assumptions where the activity permits them. Check the result against the activity's completion criteria. At each substantive delivery, state what is complete and any material unfinished work, assumptions, helpful missing information, and remaining uncertainty. Explain how these affect what the user can use, and help the user revise the result. Preserve the activity's stopping point. Do not turn a rehearsal, investigation, or test-design activity into execution that the user has not authorized. ### Establish the customer service and find its evidence Help me build an interface that lets customers ask useful questions of our data directly and receive answers from only the information they are entitled to see. Use what I have supplied to identify the customer group, service, systems, dates and likely search terms. Inspect and try available connections before asking me to gather material. Search relevant customer emails, chats and other messages, support tickets, account meeting transcripts, reports and service documents. Look for recurring questions, follow-ups, delays, definitions customers misunderstand and the answers staff currently assemble. Establish customer roles and actual needs from those records; label inferred needs as hypotheses. Search the data catalog, source inventories, table and field definitions, reporting queries, existing APIs and dashboards for the data behind those answers. Search current data-sharing policies, customer agreements, access rules, security guidance and related decisions in email, messages and documents. Record source owners, freshness, authoritative definitions and restrictions, with dated references. Follow later amendments rather than assuming an old policy still governs. Do not treat access available to an employee as permission to disclose it to a customer. If a connection fails, investigate the available setup or export route. Ask for the smallest specific action needed; explain what read-only access would enable and offer to draft an IT request if useful. With only sample or sanitized data, proceed to a demonstration and carry that limit into the result. ### Choose a useful first conversation Present a small set of frequent or consequential customer questions, grounded in the record. For each, show its audience, source data, definitions, freshness requirement and expected answer. Include a follow-up question to establish whether the interface needs a continuing conversation or a single lookup. Recommend a bounded first version. Establish the purpose before choosing software. Ask me to confirm the first customers and questions, and resolve any consequential uncertainty about access with me and the relevant owner. Wait for unresolved decisions that affect the build while continuing independent investigation. Create a concrete access map: which customer and role may read which records, fields and aggregates, through which authenticated account. Mark disputed or unknown permissions as unavailable until resolved. Include exports, downloaded charts, search results and conversation history in the same access rules. ### Build the answer path Inspect the existing customer portal and approved data tools. Choose a practical route that fits them; verify current official documentation for the actual platform before relying on a feature. Explain the proposed customer experience and the connections it needs in plain language. Build a working pilot in a suitable test environment. Connect a read-only data service to the interface. Enforce customer and role restrictions in that service or the data platform before data reaches the model; prompt wording alone is not the access control. Derive the customer identity from authenticated context, rather than letting a typed customer name grant access. For each supported question, implement the permitted lookup or calculation, check it against the original source and show the answer with its date, units, definitions and source reference. Let the interface ask a focused clarification when a question has two materially different meanings. It should identify unavailable or stale data and explain when a question needs a person. Keep factual answers distinct from interpretations or forecasts. Include useful follow-up questions without exposing the existence or details of other customers' records. Where agents help, give a builder the selected question set and data definitions, and a separate reviewer the implementation, access map and expected results. Divide large source inventories into bounded assignments with a coverage record. If agents are unavailable, use separate passes or a fresh review session and disclose shared context. ### Test usefulness and customer boundaries Create test accounts representing different customers and roles, plus an unauthenticated visitor. Test ordinary questions, ambiguous wording, missing and stale records, follow-ups, calculations and exports. Check that numbers match the source. Attempt cross-customer requests, changes of identity in the conversation, and requests to ignore access rules; confirm that the underlying service refuses prohibited data. Check that shared caches and saved conversations do not return another customer's information. Give the independent reviewer the actual interface and test cases without your explanation of why it ought to work. Have them reproduce failures and challenge unsupported answers. Repair material problems and rerun affected checks. Let me try the pilot with realistic questions and revise the experience from my feedback. ### Put the tested service into use Show what works, the test evidence, any remaining limitations and the exact deployment or integration needed. Obtain authorization before exposing a new service to customers. Within the authorized scope, complete the connection or deployment and verify it using a customer-level account. Provide the usable interface, supported questions, source and permission map, and a short operating guide. Establish who handles unanswered questions, how source freshness and failed queries are monitored, and how changes to policies or customer permissions reach the service. If access prevents a live pilot, deliver the working demonstration, its sample-data label and a precise connection handoff; do not describe that as a customer-ready service. Stop after the agreed pilot and handoff. These instructions were written in September 2026 using the frontier models available at the time. You may now have better tools or models, or restrictions that make some tasks harder. Your AI should adapt to the tools and access you actually have and find the best available way to help. Everything here is a starting suggestion for you and your AI, not a proven best practice for every setup. Feel free to rewrite any of it to better meet your needs.
View full AI instructions
Let customers query your data directly, safely.
What the AI will do
- Finds the questions customers keep asking, the data that could answer them, and the policies governing who can see what.
- Builds and tests a customer interface that can answer those questions directly, with sources and the right access for each customer.
What you can provide
- A customer group or service to start with; a rough description is enough.
- Access you can authorize to customer correspondence, support records, relevant data and policies. The AI checks what is already available first.
Where you'll take part
- Choose the first useful questions and confirm the customer access rules with the people who own the data.
- Try the interface and decide when the tested version is ready for customers.
What you'll get
A tested pilot customers can use to question their permitted data, plus the answer checks and operating instructions needed to keep it useful. If a required connection cannot be made, you receive a clearly labeled demonstration and the specific work needed to make it live.
Activity context
“Can you send me the latest numbers?” can become a conversation the customer has directly with your data. They might ask about their orders, usage, performance or another service you provide, then follow up without waiting for someone to assemble a report. Start by finding which questions are useful and which answers each customer is entitled to receive.
For the user
Start with a customer group, a recurring question or a loose description of the service. The AI will investigate the records and available connections, propose a first version, then do the building and testing. You supply the decisions about usefulness and permitted access, with the relevant data owner where needed.
Guidance for the AI
These are general instructions, not a description of this user's particular AI system, tools, access, or circumstances. Adapt the method to the user's goal and the capabilities you can actually use, while preserving the activity's essential sequence, review points, and intended result.
Start with the activity and the user's context
Read the complete activity and guide the user through it. Use the activity prompt yourself; the user does not need to paste it again. Keep the responsibilities of the user, the AI, and any colleague clear.
Begin with what the user has already supplied. Establish the intended result and resolve missing context through focused questions when needed. Work within the activity's stated scope, permissions, required confirmations, and stopping points, including any deliberate order for introducing information. Make progress with the available information and reasonable, clearly identified assumptions where the activity allows them.
Check the capabilities needed for this work
Inspect relevant available tools, connectors, and data. Use small, relevant, non-destructive checks to establish whether necessary access or a capability actually works. Naming a product does not establish access to it. Let this activity determine what needs checking; do not impose a universal preliminary questionnaire or a full system audit.
When useful access is missing:
- Explain what you cannot reach and how that material would help.
- Investigate practical setup, connection, export, or other access alternatives before asking the user to gather material or troubleshoot.
- If progress depends on access, request only the specific user action or permission needed to enable it or provide the material another way. Continue useful independent work while awaiting the response.
- Offer to walk the user through an export or upload. Welcome files, links, copied text, rough notes, or an interview as supported by your system and the activity, and use the best available route. If the missing access is optional, continue with what is available.
Ask focused questions and respect the answers
Ask questions only when necessary to complete the work well or satisfy the activity's required review points. Build on answers already supplied. Ask one question at a time, or a small group of closely related questions. Wait on work that depends on the answer, and continue useful work that does not. Explain unfamiliar language with examples where helpful.
Confirm answers or decisions you supply on the user's behalf before treating them as the user's final answers or decisions. This does not require separate approval of every sourced finding; follow the activity's specific review requirements.
Keep evidence and independent contributions distinct
Distinguish evidence, inference, and missing information. Check your work against the source material.
Use independent agents when your system actually supports delegation and independent investigation or review would improve the work:
- Give each agent a bounded brief and the context appropriate to its role.
- Keep discovery independent until synthesis where the activity requires it. Preserve any requirement for the user or colleagues to contribute before seeing other explanations.
- Follow the activity's stated fallback and any required confirmation when independent agents or fresh contexts are unavailable. Preserve reviewer isolation where required; describe shared-context or sequential passes accurately.
Produce, check, and revise the result
Do the substantive investigation and production. Carry the activity through to the most complete, usable result within its scope, rather than ending with a plan or handing the main work back to the user. When missing information does not prevent useful work, proceed with clearly identified assumptions where the activity permits them.
Check the result against the activity's completion criteria. At each substantive delivery, state what is complete and any material unfinished work, assumptions, helpful missing information, and remaining uncertainty. Explain how these affect what the user can use, and help the user revise the result.
Preserve the activity's stopping point. Do not turn a rehearsal, investigation, or test-design activity into execution that the user has not authorized.
Your AI prompt
Establish the customer service and find its evidence
Help me build an interface that lets customers ask useful questions of our data directly and receive answers from only the information they are entitled to see.
Use what I have supplied to identify the customer group, service, systems, dates and likely search terms. Inspect and try available connections before asking me to gather material. Search relevant customer emails, chats and other messages, support tickets, account meeting transcripts, reports and service documents. Look for recurring questions, follow-ups, delays, definitions customers misunderstand and the answers staff currently assemble. Establish customer roles and actual needs from those records; label inferred needs as hypotheses.
Search the data catalog, source inventories, table and field definitions, reporting queries, existing APIs and dashboards for the data behind those answers. Search current data-sharing policies, customer agreements, access rules, security guidance and related decisions in email, messages and documents. Record source owners, freshness, authoritative definitions and restrictions, with dated references. Follow later amendments rather than assuming an old policy still governs. Do not treat access available to an employee as permission to disclose it to a customer.
If a connection fails, investigate the available setup or export route. Ask for the smallest specific action needed; explain what read-only access would enable and offer to draft an IT request if useful. With only sample or sanitized data, proceed to a demonstration and carry that limit into the result.
Choose a useful first conversation
Present a small set of frequent or consequential customer questions, grounded in the record. For each, show its audience, source data, definitions, freshness requirement and expected answer. Include a follow-up question to establish whether the interface needs a continuing conversation or a single lookup.
Recommend a bounded first version. Establish the purpose before choosing software. Ask me to confirm the first customers and questions, and resolve any consequential uncertainty about access with me and the relevant owner. Wait for unresolved decisions that affect the build while continuing independent investigation.
Create a concrete access map: which customer and role may read which records, fields and aggregates, through which authenticated account. Mark disputed or unknown permissions as unavailable until resolved. Include exports, downloaded charts, search results and conversation history in the same access rules.
Build the answer path
Inspect the existing customer portal and approved data tools. Choose a practical route that fits them; verify current official documentation for the actual platform before relying on a feature. Explain the proposed customer experience and the connections it needs in plain language.
Build a working pilot in a suitable test environment. Connect a read-only data service to the interface. Enforce customer and role restrictions in that service or the data platform before data reaches the model; prompt wording alone is not the access control. Derive the customer identity from authenticated context, rather than letting a typed customer name grant access.
For each supported question, implement the permitted lookup or calculation, check it against the original source and show the answer with its date, units, definitions and source reference. Let the interface ask a focused clarification when a question has two materially different meanings. It should identify unavailable or stale data and explain when a question needs a person. Keep factual answers distinct from interpretations or forecasts. Include useful follow-up questions without exposing the existence or details of other customers' records.
Where agents help, give a builder the selected question set and data definitions, and a separate reviewer the implementation, access map and expected results. Divide large source inventories into bounded assignments with a coverage record. If agents are unavailable, use separate passes or a fresh review session and disclose shared context.
Test usefulness and customer boundaries
Create test accounts representing different customers and roles, plus an unauthenticated visitor. Test ordinary questions, ambiguous wording, missing and stale records, follow-ups, calculations and exports. Check that numbers match the source. Attempt cross-customer requests, changes of identity in the conversation, and requests to ignore access rules; confirm that the underlying service refuses prohibited data. Check that shared caches and saved conversations do not return another customer's information.
Give the independent reviewer the actual interface and test cases without your explanation of why it ought to work. Have them reproduce failures and challenge unsupported answers. Repair material problems and rerun affected checks. Let me try the pilot with realistic questions and revise the experience from my feedback.
Put the tested service into use
Show what works, the test evidence, any remaining limitations and the exact deployment or integration needed. Obtain authorization before exposing a new service to customers. Within the authorized scope, complete the connection or deployment and verify it using a customer-level account.
Provide the usable interface, supported questions, source and permission map, and a short operating guide. Establish who handles unanswered questions, how source freshness and failed queries are monitored, and how changes to policies or customer permissions reach the service. If access prevents a live pilot, deliver the working demonstration, its sample-data label and a precise connection handoff; do not describe that as a customer-ready service. Stop after the agreed pilot and handoff.
Done when
The agreed questions work in a tested interface, answers agree with their sources, and customer access boundaries have been checked. You have the operating handoff and know whether the result is live, ready to deploy or limited to a demonstration.
These instructions were written in September 2026 using the frontier models available at the time. You may now have better tools or models, or restrictions that make some tasks harder. Your AI should adapt to the tools and access you actually have and find the best available way to help. Everything here is a starting suggestion for you and your AI, not a proven best practice for every setup. Feel free to rewrite any of it to better meet your needs.
These instructions were written in September 2026 using the frontier models available at the time. You may now have better tools or models, or restrictions that make some tasks harder. Your AI should adapt to the tools and access you actually have and find the best available way to help. Everything here is a starting suggestion for you and your AI, not a proven best practice for every setup. Feel free to rewrite any of it to better meet your needs.