ChatGPT Plugin Extensions, Sites and MCP Events for Business

A customer-facing plugin is another opportunity: make your service information and supported actions available while someone is using ChatGPT to solve a problem. A customer might check service coverage, prepare a request or retrieve an authorised status. That needs its own customer journey and distribution plan. Read exposing business services through ChatGPT plugins and qualified enquiries and quote requests for the customer-facing approach. OpenAI documents specific partner conversion routes; publication alone does not guarantee their availability or recommendations. 13labs can scope the interface and the system behind it through ChatGPT plugin development.

Suppose enquiries reach a CRM but staff still read each message, research the company and decide who should respond. Some records sit without a next action. The team needs a clear queue of enquiries requiring attention, with context and an owner. Define the record before defining the interface. Include enquiry identifier, customer identifier, source message, received time, current owner, status and approved next action. Use the CRM as the source of truth for ownership and pipeline state. Decide which steps need fixed rules and which need interpretation. Routing by an explicit service region can be deterministic. Preparing a summary of a vague enquiry may suit an AI draft. A plugin should expose the smallest useful set of authorised records and actions for those tasks. Choose a business outcome: every eligible enquiry reaches an owner with enough context to reply. The design can then be assessed against assignment time, accepted briefs and missed actions. Counting how many staff opened the new panel does not establish that the sales gap improved. Use the workflow audit to compare enquiry triage with other repeated jobs before committing to the build.

A panel can help a salesperson review the draft alongside the source enquiry. A form can make the approval fields explicit. A sidebar entry can make a reusable workflow easier to find. Those are interface choices; they do not automatically create a trustworthy CRM connection. In the proposed triage workflow, show the record identifier, source message, draft brief, missing information and responsible owner. Give the reviewer a clear way to accept the brief or return it for correction. Keep an approved action distinct from a generated suggestion. The interface should reveal what will change. If an action updates an owner or saves a draft, show the target record and the fields involved. A button labelled complete is too vague when it can affect customer data. Use familiar language from the team's process. A sales owner should not have to understand MCP terminology to review an enquiry. Technical configuration belongs in the build and handover documents; the panel should support the actual decision. Check the client's supported surfaces and workspace permissions against OpenAI's extension documentation. An interface demonstrated in one client may not be available everywhere your staff work.

An internal Site could show enquiries awaiting review or a reporting dashboard. Where connected plugins are enabled, visitors use their own authorised connections. OpenAI's current launch guidance limits connected-plugin Sites to eligible workspace-private use. Check Sites documentation before scoping access. For the triage example, decide whether the Site needs a live queue or a reviewed snapshot. A live queue should identify its source, freshness and any failed retrieval. A snapshot should show when it was prepared. These designs serve different expectations. Each visitor's access can change which records appear. A salesperson may see fewer enquiries than a manager. The view should explain the scope without suggesting missing records do not exist. Keep writes narrow and visible. If the Site allows assignment, specify which users may assign which records and how the CRM confirms success. Sharing the Site should not be treated as granting permission to every source system. A useful internal tool reduces the effort of finding and acting on the right record. If the existing CRM already provides the required queue, consider adding the missing brief or review step there rather than creating a second place to check.

MCP Events allows subscribed updates to arrive through webhooks. OpenAI's integration uses the draft events specification and requires supported MCP 2.0 behaviour. See the official MCP Events guide for supported delivery and subscription requirements. For the proposed workflow, an event might identify a newly created enquiry. The event should contain a stable identifier and enough information to retrieve the authorised source record. It should not substitute an unverified message for the record itself. Define which events deserve work. A new enquiry, a duplicate import and an edit to an old record are different situations. Apply filters so the workflow does not prepare the same brief for every unrelated update. Plan for repeated delivery. Keep a record of the event identifier and accepted action so the system can detect duplicates. If two updates concern the same enquiry, read the current CRM state before creating another action. Define failure separately from no eligible event. The team needs to know whether there were no new enquiries or the connection stopped delivering. Assign an owner to monitor that distinction and document how to pause the subscription.

Sign in with ChatGPT can identify a user in a participating application. Eligible integrations may also use the user's ChatGPT plan for AI requests, subject to the available integration route and limitations. Commercial availability is limited; do not assume a new business app can immediately use subscription-funded inference. Check the official quickstart. Keep identity and source access separate in the scope. Knowing who signed in with ChatGPT does not establish their permission to read a CRM record. The app must still authorise the relevant account and action through the source system and its own access rules. Also separate identity from billing. A sign-in button may provide account access without paying for all AI calls. The implementation needs an explicit inference route, usage limits and a response when the allowance is unavailable. If the app is not eligible for plan usage, assess a standard API-backed design with its own budget. That is a practical fallback, not something to conceal until after the customer commits to the build. For an internal tool, document how accounts are linked and removed when a staff member changes role. A convenient sign-in flow is useful only when the team can also control access over time.

Start with an approved sample of enquiries and a draft-only brief. Use a read connection, one review surface and a named salesperson. Add event delivery after the brief has proved useful; this avoids debugging interface, content and trigger problems simultaneously. The pilot should answer whether the correct enquiry is retrieved, whether the draft is supported by sources, whether the reviewer understands the action, and whether accepted work appears in the agreed destination. Include an unassigned enquiry, a duplicate record, a record outside the reviewer's access and a changed enquiry. Check that unavailable access remains an exception rather than becoming a confident empty response. A worked example might involve 25 enquiries a week taking 8 minutes each to prepare: 200 minutes of effort. If the pilot needs 4 minutes of review per enquiry, routine effort becomes 100 minutes. The possible saving is 100 minutes before maintenance and exceptions. These are assumptions for planning, not product results. Track accepted briefs and time to a useful sales response. If another dashboard simply becomes another queue to monitor, revise the design. The aim is fewer missed steps in revenue automation, with ownership retained in the sales process.

Document which source account is connected, permitted records and actions, event filters, output location and failure owner. Include a way to revoke access and pause the workflow. Record how a new teammate obtains access and what changes when the original creator leaves. A personal connection that quietly powers a team process can create an avoidable support problem. Agree on the review cadence for product changes and source permissions. Draft specifications and limited rollout mean the implementation may need updates. Put that maintenance responsibility into the scope. 13labs can build the difficult integration or work with the team through buildAutomation. For a separate customer-facing product, buildAgency provides the custom-software route. The decision should follow the workflow and user needs.

Do we need all four features for one workflow? No. Start with the missing step. You may need an authorised connection and a draft brief without a Site, event subscription or new sign-in route. Do MCP Events replace our existing automation platform? They provide one way to trigger subscribed work. Compare the actual workflow, failure handling and ownership before replacing a working process. Can any app use a customer's ChatGPT subscription? Do not assume that. Identity and plan usage have separate requirements, and commercial access is limited. Verify eligibility and document the billing fallback.

Product facts checked on 1 October 2026: extensions, MCP Events, Sites and Sign in quickstart. Run the workflow audit, then discuss your CRM handoff with a specific input, output and responsible owner.