How to Build a ChatGPT Plugin for Your Business

Write a brief that names the customer, their question and the result: a facilities manager can check whether a machine and location fall within our stated service scope. Define what happens when the answer is uncertain. Choose an owner for the information. The service manager approves equipment categories and exclusions. Operations owns coverage. A developer should not have to interpret an old sales brochure to determine where the business works. Set the first boundary: information only, with no booking or CRM write. That makes it possible to verify the answer independently before adding an action. If customers mainly need a familiar explanation rather than live information, consider whether reusable instructions and reference material are sufficient. OpenAI's architecture guide describes skills, MCP server tools and optional UI. MCP means Model Context Protocol: the connection through which ChatGPT can call capabilities you provide.

Use a focused action such as check_service_fit. Define its inputs and outputs before implementation. An example brief might specify equipment_category and suburb as inputs, with coverage_status, service_id, explanation and information_updated_at as outputs. Keep the possible coverage results explicit: supported, outside_scope or needs_assessment. Missing information should have its own response. An outage should produce unavailable, not outside_scope. These are proposed field names, not a required OpenAI schema. Describe when the tool should run and what it cannot establish. A request for general maintenance advice should not trigger a service-fit lookup unless the user is asking about this provider. OpenAI's tool planning guidance is useful when turning that brief into names, schemas and handlers.

Choose a language your team can maintain. OpenAI documents Python and TypeScript MCP SDKs and a Streamable HTTP endpoint in its server build guide. Follow that guide for the current SDK imports and registration syntax. Connect the handler to the approved catalogue. Validate inputs, perform the lookup and return structured results that distinguish known facts from missing information. Keep service credentials on the server. A business catalogue does not need to be pasted into every customer conversation. A developer can test the handler before connecting ChatGPT: a supported machine and location, an excluded category, a missing suburb and an unavailable catalogue. Each case should have an expected result. The language model should not be responsible for enforcing coverage rules.

Public scope and coverage information may be suitable for an anonymous lookup. Customer contracts, request history and account-specific prices require a different access design. Keep those out of the first tool unless they are necessary to complete its task. If you later add get_request_status, resolve the customer from validated account credentials and check access to the requested record. A supplied reference number does not prove ownership. Use the authentication documentation when designing the connection. Do not turn a prototype's shared administrator credential into a customer-facing access model. The prototype may show that the source is reachable while revealing nothing about whether customer access is correct.

Use the current personal-plugin quickstart to connect the MCP endpoint in developer mode. OpenAI's example creates a personal plugin and invokes it in a Work chat. Follow the interface available to your account; workspace controls can affect access. Test direct requests that name the business and indirect requests that describe the task. Include prompts that should not call your tool. Record the selected tool, supplied inputs, returned result and final explanation. For the maintenance example, try a recognised category, an informal machine description, an unsupported suburb and a request to book immediately. The last case must respect the information-only scope. A plausible reply is not sufficient if it hides an incorrect lookup.

A personal connection, a workspace rollout and a public directory release have different distribution requirements. Decide which you need before investing in listing material. A staff tool does not automatically need a public launch. Follow the package guide for the manifest and included components. Keep the package's purpose consistent with the tools you tested. A listing that promises bookings when the server only checks coverage sets the wrong expectation. For public release, follow the submission process and allow for review. Build completion is a milestone you control; approval timing is not. The separate publishing walkthrough explains how to prepare the release evidence.

Record where service information lives, who approves changes and how they reach the plugin. A new equipment category should not require someone to rediscover the original project. Keep a small set of test requests alongside the implementation. Agree what the team sees when the catalogue cannot be read. Monitor failed lookups and unresolved customer tasks with appropriately disclosed data practices. Avoid collecting whole conversations merely because they might be useful later. Add actions only after the lookup proves useful. A supported enquiry handover needs its own acceptance criteria, duplicate handling and operational owner. Read connecting a plugin to a CRM before adding that next step.

Do I need a custom interface? Only when it helps the customer complete the task or the chosen integration requires it. A clear information result can be enough for the first version. Can I launch from a demonstration in my own account? Treat that as evidence for the tested account and cases. Public release needs its own package, access checks and review process. What should I bring to a developer? Bring one customer question, the authoritative information, expected results for difficult cases and the person who owns the process.

Product documentation checked on 5 October 2026. The example contracts and test cases are design recommendations. If you want the connection built and handed over, discuss a business plugin with the customer task and source system in view.