Getting Fin to answer questions is a strong first step. Procedures take that further by helping Fin resolve repeatable, multi-step issues - not just to explain a process, but actually complete it.
To do that, Fin usually needs access to information or actions in your internal systems, which means you may need some help from engineering or from the team that owns those systems internally.
This guide is for support and operations leaders who are championing Procedures internally. It will help you scope the ask, speak to technical stakeholders with confidence, and keep the first project small enough to get approved.
Why this matters
Fin already handles informational questions well. Procedures unlock a different kind of value: resolving issues that depend on real-time data or system actions, like checking an order status, looking up a subscription, or processing a return.
That is where the internal advocacy work begins. If a customer issue depends on live data or a system action, your team will need Data Connectors and API access to make that experience possible.
The opportunity is not just deflection. It is faster resolution, less repetitive manual work, and a smoother customer experience for your highest-volume tasks.
Without Procedures vs. with Procedures
Without Procedures | With Procedures |
Fin tells a customer how to submit a damaged order claim. | Fin processes the claim, checks the order status in your database, and confirms the replacement — all in one conversation. |
Fin tells a customer to log in to check their subscription renewal date. | Fin looks up the renewal date and subscription status in real time and gives the customer an immediate answer — no log-in required. |
According to Intercom's 2026 Customer Service Transformation Report, teams that integrate AI into real workflows, rather than stopping at surface-level FAQs, report significantly stronger ROI and improved metrics. Most teams are investing in AI, but only a small minority have reached mature deployment.
Start before engineering: what you can do now
Not every Procedure requires engineering work. Before involving technical stakeholders, explore what you can build with what you already have.
Procedures that don't need Data Connectors:
Guided troubleshooting flows using knowledge base content
Step-by-step walkthroughs that collect information and route to the right team
Triage procedures that ask qualifying questions before escalating
Policy enforcement flows (e.g., warranty eligibility checks based on purchase date)
Procedures using the Ask Teammate step:
If a Procedure needs information from another system but engineering isn't available yet, you can use the Ask Teammate step as a stand-in. A teammate manually completes that step while the Data Connector is being built, so you can test the full procedure flow end-to-end and gather data on its impact.
Starting here gives you two advantages: you learn how to build Procedures, and you generate measurable results that make the case for engineering investment when you need it.
Tip: Teams can now build and manage Procedures using natural language, apply the controls and data needed for accuracy, and test every scenario before it reaches a customer. Many of the building blocks like descriptions, triggers, conditions, guidance, don't require technical skills at all.
New to APIs and Data Connectors?
If you are new to these terms, this section covers what you need to know to scope the ask and explain it internally.
An API (Application Programming Interface) is a structured way for software systems to exchange information. When one system needs a piece of data from another, it sends a request through an API and receives a response.
A Data Connector uses an API call so Fin can securely retrieve or send a specific piece of information, like an order status or a subscription renewal date. Each connector is usually designed for one specific task. Learn more about Data Connectors.
A Procedure uses those connectors inside a multi-step process, so Fin can do more than answer a question, it can help resolve the issue. Learn more about Procedures.
For your first project, start small, one repeatable process, one system, and only the few data fields Fin actually needs. The more focused the ask, the faster it moves.
Example: how the pieces connect
Customer goal: “Check my subscription renewal date”
Procedure: Fin confirms identity, calls the billing system, and returns the renewal date, all in one conversation
Data Connector: One read-only API call to the billing platform, returning three fields: renewal date, plan name, subscription status
Result: Fin answers in seconds. No teammate needed
Fin does not need access to your whole system. It usually needs one secure way to retrieve or send a small set of approved data. Engineering or the system owner defines exactly which fields Fin can access, nothing more.
For the full technical setup refer to the article, designing and using your APIs with Data connectors.
How to pick your first Procedure
The best internal case starts with a concrete process, not a feature pitch. Before you involve engineering, write down the exact process you want to automate and the minimum data Fin needs to do it well.
A good first Procedure is usually narrow, repetitive, and already well understood by your support team.
Pro tip: Choose the most valuable process you can automate with the fewest endpoints and the smallest set of fields. A Procedure that reads a few fields from one system is far easier to get approved, built, and launched than one that touches multiple systems. Start narrow — complexity can come later once the first win is secured.
Selection criteria
Use the criteria below to identify your best candidate:
Criteria | What to look for |
Volume | A high-frequency issue your team handles repeatedly |
Repeatability | A process with consistent steps that doesn't require human judgment each time |
API availability | A well-documented API already exists (e.g. Stripe, Shopify) or can be scoped quickly |
System ownership | You know which internal team or tool owns the data or action (e.g. "that's in Salesforce" or "our billing team handles that") |
Engineering ask clarity | You can describe what Fin needs in one sentence without using technical terms. Fin only needs a small number of fields from one system |
Measurability | You can define a clear success metric before you build (e.g. resolution rate) |
Example: a good first Procedure
Use case: Check subscription renewal date
System: Billing platform
What Fin needs: Renewal date, plan name, subscription status — three fields from one endpoint
First ask: "We need one read-only endpoint that returns these three fields for an authenticated customer."
Why it works: High-volume, repetitive, low risk, and easy to measure. Requires no write access and a minimal lift from engineering or the system owner.
Think in phases, not all at once
The most successful teams adopt Procedures in stages:
1. No integration needed: Automate FAQ-style flows, troubleshooting guides, and routing logic using knowledge base content alone.
2. Read-only access: Connect Fin to one system to look up information (e.g., order status, account details, subscription dates). This is where the first Data Connector comes in.
3. Write actions: Allow Fin to take action in another system (e.g., process a refund, cancel a subscription, update a record). This requires deeper engineering involvement and usually comes after trust is established.
Starting with Phase 1 or 2 means you can show results quickly, and use those results to build the case for Phase 3.
Tip: The Recommendations dashboard Fin AI Agent > Analyze > Recommendations is the fastest way to find your best Procedures candidates.
Filter by Customer data gaps: where Fin needed information from an external system like order status or account details
Filter by Action gaps: where Fin needed to take an action in another system like canceling an order or updating a record.
Each recommendation includes a guide outlining the API and data needed, making it a ready-made brief for your engineering conversation. Pull a sample of conversations from the Recommendations dashboard, identify specific customer intents that could become Procedures, and estimate the resolution rate improvement based on how often those requests appear. This turns a general idea into a concrete, scoped plan.
Map the process before the meeting
Before you approach engineering or the team that owns the relevant system, map out exactly what you want to automate. This is the single most important step — a well-mapped process makes the technical conversation faster and the ask harder to say no to.
How to map it
1. Write out the process step by step in plain language. What triggers it? What happens at each step? What does the customer receive at the end?
2. Highlight exactly where Fin needs data from another system or needs to take an action. These are your Data Connector touchpoints.
3. For each touchpoint, list the specific data fields Fin needs. Not the whole database — just the minimum fields for this process.
4. Identify which team owns each system. This is not always engineering. It could be the team that administers Salesforce, Jira, your billing platform, or another internal tool.
What to bring to the meeting
The mapped process with clear Data Connector touchpoints
The specific fields Fin needs at each step (e.g., "order status, tracking number, estimated delivery date")
A success metric you can measure before and after (e.g., "resolution rate for order status queries")
Volume data showing how often this issue comes up (pull this from the Recommendations dashboard or your reporting)
Pro tip: Consider mapping the process visually in a tool like Miro or a simple flowchart. This helps everyone, including non-technical stakeholders, see the full picture and identify where the engineering work actually is.
Who's involved and what they do
Getting a Procedure built requires two kinds of alignment: clarity on who owns what day-to-day, and knowing which stakeholders need to be engaged to get approval.
Day-to-day ownership
CX / Support Team | Engineering team |
Write and update the Procedure in natural language using steps, tools, and guidance within Intercom | Expose system access via Data Connectors (authenticated API calls) |
Define the Procedure logic, testing scenarios, and success metrics | Define the endpoint, request type (e.g. GET, POST), and specific fields Fin is permitted to use |
Own iteration after launch | Set authentication headers or tokens and confirm security constraints
|
Who needs to be in the room
Role | Who they typically are | What they contribute |
Champion | Support or operations lead driving the initiative | Maps the process end-to-end and defines what Fin needs to do it well |
Direct sponsor | Head of support, CX, or operations | Approves the Procedure as a priority and gives the champion the mandate to move forward |
System owner | The team or individual responsible for the relevant internal tool (e.g., Salesforce admin, billing team lead, Jira owner) | Confirms what data exists, who can access it, and what constraints apply |
Technical lead | Developer, architect, or engineering lead for the system being connected | Aligns on feasibility, defines the endpoint and permitted fields, and confirms the timeline |
This is not always an engineering conversation. If the data Fin needs lives in Salesforce, Jira, your billing platform, or another internal tool, the key stakeholder may be the team that owns that system, not a software engineer. Identify the system owner first, then determine whether engineering involvement is needed.
The business case by stakeholder
The same Procedure can be framed very differently depending on who is in the room. Before you prepare the pitch, find out which priorities your leadership is already accountable for, then frame the Procedure as a direct contribution to one of those goals.
For engineering leads it's best to keep the ask bounded
"We're not asking engineering to own an AI workflow. We're asking for help exposing one secure endpoint so the support team can automate a high-volume, repeatable process ourselves. Once the endpoint is in place, the CX team builds and maintains the Procedure independently, no ongoing engineering involvement"
What to share: The specific endpoint, the fields needed, the request type (GET or POST), and the authentication method. The more precise the ask, the easier it is for an engineer to estimate and schedule.
Addressing the time investment: For teams with well-documented APIs, the Data Connector setup is typically a contained piece of work. We have seen a customer's dev team getting a read-only connector running in under an hour. The scope is similar to building any other API integration, not a new system.
For support and CX leadership it's best to focus on resolution
"Without this integration, Fin can only explain the process. With it, Fin can complete the process. This removes avoidable human effort and makes the customer experience feel instant."
What to share:The volume of conversations this Procedure would handle, the current average handle time, and the expected improvement in resolution rate.
For executive leadership it's best to align to an existing priority
"Tell us the goal you are already being measured on — whether that is CSAT, handle time, or reducing manual load — and we will scope this Procedure to show a direct result against that. This does not need its own business case. It is a direct contribution to something you are already tracking."
A note on framing: For some organisations, the dollar value of automation is significant. For others, the financial savings from a single Procedure may not move the needle on their scale. In those cases, lead with the qualitative impact: improved customer experience scores, faster resolution, and reduced friction in high-volume workflows. Know your audience and lead with what matters most to them
Handling common pushback
They say... | You say... |
"We don't have capacity." | "That's why this is a narrow pilot. By removing this recurring manual load from the team, we actually create capacity for future sprints." |
"We don't want broad system access." | "Data Connectors are scoped to specific endpoints and response fields. We can start with read-only access to ensure security." |
"We need the API fully built first." | "We can start designing now. Intercom supports example JSON responses in setup, and we can validate the logic using Simulations before the API is live." You can also use the Ask teammate step as a temporary stand-in, it lets a teammate manually complete that step while the connector is being built, so you can test the full procedure flow end to end. |
"It's not on our roadmap this quarter." | "Understood. Can we get it into the next planning cycle? In the meantime, we'll have the process mapped, the fields documented, and the success metric defined — so when capacity opens up, the ask is ready to go." |
Once you have engineering alignment, share the Create data connectors for Fin guide with your developer or system owner. It covers the full setup process including API connection, authentication, data transformation, and testing.
If internal resources are limited
Sometimes the real blocker is roadmap timing. Engineering may be supportive in principle but not available until the next planning cycle. That is a reasonable outcome, not a failure.
What to do while you wait
1. Map the process end-to-end in plain language. Document every step, every data field, and every system touchpoint.
2. Build Procedures that don't need Data Connectors. Guided troubleshooting, triage flows, and knowledge-based automation all create value now.
3. Use the Ask Teammate step as a bridge for steps that will eventually use a Data Connector.
4. Gather volume data and track results from the Procedures you've already built — this becomes the evidence for your next request.
5. Narrow the scope as much as possible so the engineering ask is ready to slot in when capacity opens up.
Get outside help
Join weekly Intercom Community Meetup Office Hours for Q&A and mentor-led support
To get scoping help, talk through blockers, and hear how other teams have navigated similar internal conversations. Broadly useful and free to attend
Hire an Expert for 1:1 Personalised Support
For more hands-on, dedicated support, the verified Experts Program connects you with independent consultants and developers who specialise in Fin and Data Connectors. A good option if you want 1:1 guidance and are willing to invest in a more bespoke path
Tip: The Quick start: Create a Fin Procedure walks you through building your first Procedure step by step, including a worked example using a Data Connector.
Related resourses
FAQs
Do we need to build a new API to use Procedures?
Do we need to build a new API to use Procedures?
Not necessarily, if a well-documented API already exists (e.g. Stripe or Shopify), this is typically a contained, low-lift integration. Engineering just needs to expose the specific endpoint and fields Fin is permitted to use.
Can we test a Procedure before the API is ready?
Can we test a Procedure before the API is ready?
Yes, Intercom supports example JSON responses in setup, so you can build and validate the logic using Simulations before the live API is connected.
Does engineering need to build the Procedure itself?
Does engineering need to build the Procedure itself?
Usually not, the support or operations team owns the Procedure logic — writing the steps, testing it, and iterating after launch. Engineering or the system owner enables the data layer: exposing the right endpoint, defining which fields Fin can access, and setting the authentication method. Once that is in place, the CX team can build and update the Procedure independently.
What if we can only get read-only API access to start?
What if we can only get read-only API access to start?
That's a perfectly valid starting point. A read-only Procedure, for example, looking up a subscription status or order details, still removes meaningful manual effort and gives you a measurable result to build on.
How long does it typically take for engineering to set up a Data Connector?
How long does it typically take for engineering to set up a Data Connector?
It depends on the complexity, but for teams with well-documented APIs, a read-only Data Connector can be set up relatively quickly — sometimes in under an hour. The scope is similar to building any standard API integration: define the endpoint, set the authentication, map the response fields. The CX team handles everything else.
Can we build Procedures without any engineering involvement?
Can we build Procedures without any engineering involvement?
Yes. Procedures that use knowledge base content, guided troubleshooting flows, triage logic, or the Ask Teammate step don't require Data Connectors or engineering work. These are a great place to start and build confidence before expanding into connected Procedures.
Need more help? Get support from our Community Forum
Find answers and get help from Intercom Support and Community Experts