Give your department an AI front desk.
How do people get something done with your department? They may need to know whom to ask, which system to use and whether anybody saw their last message. Give them one place to start—and give your team one place to see the whole exchange, from the first question to what happened after the answer went out.
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
- Studies the questions, requests and collaborative projects reaching your department, including how people handle them now.
- Builds and tests one portal that answers questions, gathers requests, routes work and tracks what happens afterwards.
What to have ready
- Your department name and a rough description of whom it serves; existing materials are welcome.
- Access to relevant messages, department documents and work systems, or usable exports where connections are unavailable.
Where you come in
- Confirm the people the portal should serve, including frequent contacts outside your organization.
- Choose what it can answer and route itself, then try the finished experience and authorize its launch.
What you'll get
A working department front desk and a shared record of requests, ownership, responses and follow-through. If a required connection is blocked, you receive the working portions and prepared integration, with launch clearly marked as unfinished.
You're done when
People can use the portal to get supported answers or submit work, the right destination receives it, and the department can trace ownership, responses and subsequent outcomes in one place. Any unavailable integration remains an explicit unfinished part.
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. Build a consolidated AI front desk for my department: one portal for colleagues and, where relevant, people at other organizations who work with us frequently. It should answer questions conversationally, accept new requests and collaborative projects, send work to the appropriate system or person, and show what happened throughout the exchange. ### Discover how people work with us Start with what I have supplied. Identify the department, likely users and intended result. Inspect and try relevant connections before asking me to assemble material. Search department email and chats, including WhatsApp where accessible, meeting transcripts and calendar invitations for recurring questions, requests, joint projects, handoffs and follow-up. Search request queues, project boards, shared documents, service descriptions, FAQs, policies and team responsibilities for how work is supposed to be handled. Follow representative cases from arrival through delivery and later use. Establish who actually approaches us and what they need from their messages, roles, meeting participation and prior exchanges. Include frequent external collaborators where the record supports them. Distinguish their expressed concerns from your interpretation. Identify preferred language, useful terminology, repeated missing details, unanswered questions and places where an apparently completed request reappeared. Keep source references and a coverage record of channels, dates, request types and gaps. Split a large record into bounded assignments by channel or request family, giving each agent actual sources, the same case fields and a clear completion point. Reconcile duplicates and disagreements yourself. If agents are unavailable, use manageable successive passes and preserve the same handoff record. If access fails, investigate supported connection or export options, then ask for the specific missing action. Work with the sources you can inspect. Explain when a rough interview can establish an intended workflow but cannot establish how past requests were handled. ### Agree on the front desk's job Present a concise map of the main questions, requests and collaborative projects: who brings each, what information is needed, who owns it, what platform holds the work, what goes back and what happens afterwards. Resolve consequential ambiguities one at a time. Establish the first launch audience and request families, incorporating prior decisions rather than reopening them. Show the proposed experience with actual examples. A question may get an answer linked to current departmental guidance. A new request may get a short conversation that collects missing information and creates a work item. A collaborative project may need several owners, milestones and linked tasks. Let a person move between these paths without starting over. Confirm source visibility for internal and external users, which answers and routing actions can happen automatically, and which require a named person's decision. Do not infer that access to a department inbox gives every portal visitor access to its contents. Agree on who maintains ownership and answers when the department changes. ### Build the portal and the record behind it Inspect the organization's existing portal, chat and work platforms and their current official integration documentation. Choose a supported route fitted to the actual setup and build it with the available tools. If installation needs an action only I can take, prepare the configuration and ask for that precise action. A design description is not the completed portal. Implement the conversational question service using the approved sources, with source links and an explicit route to a person when evidence is missing or conflicting. Implement intake for agreed request and project types, collecting only relevant missing details and showing the requester what will happen next. Wire these into the actual destination platforms or named team members under the agreed authorization. Record destination IDs and verify successful creation or delivery rather than treating an attempted call as completion. Create one consolidated view of the exchange. Give each request a stable identity and record its source, requester, purpose, owner, current state, handoffs, linked work, outgoing answer or deliverable and subsequent feedback or outcome. Link to existing authoritative work records and synchronize their status so the portal can show a single coherent history. Handle repeated messages about the same request without creating duplicate work. Define how an outcome will be learned: a downstream system event, recorded use, or an agreed follow-up. If it is unknown, display that honestly. ### Test the whole experience Use representative historical cases in a test environment and run new end-to-end trials. Cover a sourced answer, an incomplete request, a multi-person collaboration, a changed owner, a repeated request, a failed destination connection and follow-up after delivery. Test internal and external visibility separately. Verify the actual work item or message at its destination and the returning status in the portal. Have a fresh reviewer, where available, attempt these journeys using the portal and permitted sources without your explanation of the intended experience. Give them bounded cases and ask them to identify confusing interactions, unsupported answers and lost handoffs. Keep simulated user reactions distinct from feedback from actual stakeholders. Repair failures and recheck the affected path. ### Launch and hand over Show me the working portal, example case histories, test results, launch audience and automatic actions. Once launch is authorized, activate it and verify a permitted live exchange from intake to destination and back into the consolidated record. Give me the portal link, owner view, update instructions, connection health and the way to pause automation or change routing. If a genuine missing connection prevents launch, deliver the working portions, exact integration package and the smallest action needed to finish. State which paths are tested, which remain disconnected and what completion still requires. Do not describe a mockup or configuration document as an operating front desk. 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
Give your department an AI front desk.
What the AI will do
- Studies the questions, requests and collaborative projects reaching your department, including how people handle them now.
- Builds and tests one portal that answers questions, gathers requests, routes work and tracks what happens afterwards.
What you can provide
- Your department name and a rough description of whom it serves; existing materials are welcome.
- Access to relevant messages, department documents and work systems, or usable exports where connections are unavailable.
Where you'll take part
- Confirm the people the portal should serve, including frequent contacts outside your organization.
- Choose what it can answer and route itself, then try the finished experience and authorize its launch.
What you'll get
A working department front desk and a shared record of requests, ownership, responses and follow-through. If a required connection is blocked, you receive the working portions and prepared integration, with launch clearly marked as unfinished.
Activity context
How do people get something done with your department? They may need to know whom to ask, which system to use and whether anybody saw their last message. Give them one place to start—and give your team one place to see the whole exchange, from the first question to what happened after the answer went out.
For the user
Start with your department name or a rough description. The AI will investigate how work arrives, build the portal and test its connections. You will confirm who it serves, resolve choices about ownership and access, and approve the tested launch.
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
Build a consolidated AI front desk for my department: one portal for colleagues and, where relevant, people at other organizations who work with us frequently. It should answer questions conversationally, accept new requests and collaborative projects, send work to the appropriate system or person, and show what happened throughout the exchange.
Discover how people work with us
Start with what I have supplied. Identify the department, likely users and intended result. Inspect and try relevant connections before asking me to assemble material. Search department email and chats, including WhatsApp where accessible, meeting transcripts and calendar invitations for recurring questions, requests, joint projects, handoffs and follow-up. Search request queues, project boards, shared documents, service descriptions, FAQs, policies and team responsibilities for how work is supposed to be handled. Follow representative cases from arrival through delivery and later use.
Establish who actually approaches us and what they need from their messages, roles, meeting participation and prior exchanges. Include frequent external collaborators where the record supports them. Distinguish their expressed concerns from your interpretation. Identify preferred language, useful terminology, repeated missing details, unanswered questions and places where an apparently completed request reappeared.
Keep source references and a coverage record of channels, dates, request types and gaps. Split a large record into bounded assignments by channel or request family, giving each agent actual sources, the same case fields and a clear completion point. Reconcile duplicates and disagreements yourself. If agents are unavailable, use manageable successive passes and preserve the same handoff record.
If access fails, investigate supported connection or export options, then ask for the specific missing action. Work with the sources you can inspect. Explain when a rough interview can establish an intended workflow but cannot establish how past requests were handled.
Agree on the front desk's job
Present a concise map of the main questions, requests and collaborative projects: who brings each, what information is needed, who owns it, what platform holds the work, what goes back and what happens afterwards. Resolve consequential ambiguities one at a time. Establish the first launch audience and request families, incorporating prior decisions rather than reopening them.
Show the proposed experience with actual examples. A question may get an answer linked to current departmental guidance. A new request may get a short conversation that collects missing information and creates a work item. A collaborative project may need several owners, milestones and linked tasks. Let a person move between these paths without starting over.
Confirm source visibility for internal and external users, which answers and routing actions can happen automatically, and which require a named person's decision. Do not infer that access to a department inbox gives every portal visitor access to its contents. Agree on who maintains ownership and answers when the department changes.
Build the portal and the record behind it
Inspect the organization's existing portal, chat and work platforms and their current official integration documentation. Choose a supported route fitted to the actual setup and build it with the available tools. If installation needs an action only I can take, prepare the configuration and ask for that precise action. A design description is not the completed portal.
Implement the conversational question service using the approved sources, with source links and an explicit route to a person when evidence is missing or conflicting. Implement intake for agreed request and project types, collecting only relevant missing details and showing the requester what will happen next. Wire these into the actual destination platforms or named team members under the agreed authorization. Record destination IDs and verify successful creation or delivery rather than treating an attempted call as completion.
Create one consolidated view of the exchange. Give each request a stable identity and record its source, requester, purpose, owner, current state, handoffs, linked work, outgoing answer or deliverable and subsequent feedback or outcome. Link to existing authoritative work records and synchronize their status so the portal can show a single coherent history. Handle repeated messages about the same request without creating duplicate work. Define how an outcome will be learned: a downstream system event, recorded use, or an agreed follow-up. If it is unknown, display that honestly.
Test the whole experience
Use representative historical cases in a test environment and run new end-to-end trials. Cover a sourced answer, an incomplete request, a multi-person collaboration, a changed owner, a repeated request, a failed destination connection and follow-up after delivery. Test internal and external visibility separately. Verify the actual work item or message at its destination and the returning status in the portal.
Have a fresh reviewer, where available, attempt these journeys using the portal and permitted sources without your explanation of the intended experience. Give them bounded cases and ask them to identify confusing interactions, unsupported answers and lost handoffs. Keep simulated user reactions distinct from feedback from actual stakeholders. Repair failures and recheck the affected path.
Launch and hand over
Show me the working portal, example case histories, test results, launch audience and automatic actions. Once launch is authorized, activate it and verify a permitted live exchange from intake to destination and back into the consolidated record. Give me the portal link, owner view, update instructions, connection health and the way to pause automation or change routing.
If a genuine missing connection prevents launch, deliver the working portions, exact integration package and the smallest action needed to finish. State which paths are tested, which remain disconnected and what completion still requires. Do not describe a mockup or configuration document as an operating front desk.
Done when
People can use the portal to get supported answers or submit work, the right destination receives it, and the department can trace ownership, responses and subsequent outcomes in one place. Any unavailable integration remains an explicit unfinished part.
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.