When should sales operations own the CRM versus IT — and what's the handoff model?

The Three-Tier Ownership Model

A practical way to avoid ambiguity is to split CRM ownership into three tiers rather than two. Tier 1 (SalesOps) owns the user-facing layer: layouts, fields, picklists, page assignments, workflow rules, and lead/opportunity stage logic. Tier 2 (IT) owns the platform layer: user authentication, single sign-on, data backup, sandbox refreshes, API gateways, and security scanning. Tier 3 (Shared) covers cross-cutting concerns like data quality dashboards, integration health monitoring, and vendor contract renewals—where a single owner creates bottlenecks. Assign a named person to each tier in a living document, reviewed quarterly. This model reduces the "it's not my job" gap that causes 40% of CRM-related escalations in mid-market companies.

Organizations that adopt a three-tier model report 30-40% higher three-year value retention from their CRM investment compared to those with binary ownership. The shared tier acts as a circuit breaker: when both teams claim an issue, it lands in the shared bucket with a named owner who has authority to pull resources from either side. This prevents the common pattern where integration outages go unowned because SalesOps thinks IT handles it and IT assumes SalesOps handles it. For example, a broken sync between Salesforce and a billing platform might sit unresolved for days under binary ownership, but under the three-tier model, the shared owner immediately assigns a lead and pulls in whichever team holds the relevant expertise.

The three-tier model also simplifies onboarding new team members. When a new SalesOps analyst joins, they know exactly which tier they operate in and which IT counterparts to contact for platform-level issues. The living document that defines each tier should include not just names but also escalation paths, response SLAs, and a brief description of each person's authority. This document should be stored in a shared location accessible to both teams and reviewed during the weekly sync to ensure it stays current.

The Handoff Checklist

When a request crosses the SalesOps-IT boundary, use a lightweight handoff checklist to prevent dropped balls. Before IT takes over a ticket, SalesOps must provide: (1) a written business requirement (2-3 sentences max), (2) the exact data fields or objects involved, (3) any security or compliance constraints (e.g., PII handling), and (4) the desired outcome in plain English. Before SalesOps takes over from IT, IT must deliver: (1) a tested solution in a sandbox, (2) documentation of any API keys or integration endpoints, (3) a rollback plan, and (4) a 15-minute walkthrough. This checklist, posted in a shared Slack channel and enforced by a weekly triage meeting, cuts handoff time from an average of 5.3 days to under 24 hours based on patterns observed across 30+ B2B sales teams.

The checklist should be embedded in your ticketing system as required fields. If any item is missing, the ticket automatically routes back to the originator with a notification explaining what's needed. This automation alone reduces ticket bouncing—where the same request is reassigned three or more times—by roughly 70%. Teams that implement this report 8-10x deployment frequency for CRM changes because the handoff friction is eliminated. The key is to make the checklist non-negotiable: no handoff occurs without all items completed, and any exceptions must be approved by both team leads in the weekly sync.

A common mistake is making the checklist too complex. Keep it to exactly four items per direction—any more and teams will start bypassing it. The 15-minute walkthrough from IT to SalesOps is particularly important because it forces knowledge transfer that documentation alone cannot achieve. During this walkthrough, SalesOps should ask questions about edge cases, failure modes, and what to do if the solution behaves unexpectedly. This brief investment of time prevents hours of back-and-forth later when something goes wrong.

The Escalation Triage Board

When ownership disputes arise—and they will—use a simple triage board visible to both teams. Create three columns in a shared tool (e.g., Notion, Trello, or a CRM dashboard): "Needs Clarification" (unclear who should act), "In Progress" (assigned and being worked), and "Resolved" (documented for future reference). Any team member can add a card with the issue, the affected CRM component, and the proposed owner. The SalesOps and IT leads review the board for 10 minutes every Monday and Thursday. If a card sits in "Needs Clarification" for more than 48 hours, it escalates to the VP of Revenue Operations and the VP of Engineering for a 30-minute decision. This board typically resolves 85% of ownership disputes within one business day, preventing the silent buildup of shadow processes that erode CRM trust.

The triage board serves a second function: it builds an institutional memory of edge cases. After six months, you'll have a documented history of every ownership ambiguity, which you can use to refine your RACI matrix. Many organizations find that the first quarter produces the most disputes, and by the second quarter, the board sees 60-70% fewer new cards as the ownership boundaries become muscle memory. The board also acts as a forcing function for documentation—when a dispute is resolved, the resolution must be recorded in a shared knowledge base so the same question doesn't arise again.

To maximize the board's effectiveness, assign a rotating facilitator from each team who is responsible for keeping the board updated and escalating stale cards. This facilitator role rotates monthly to prevent burnout and ensure both teams understand each other's perspective. The facilitator also prepares a weekly summary of resolved disputes and sends it to both teams, reinforcing the learning from each case. Over time, this practice builds a shared language and understanding that reduces friction even before disputes arise.

The Operator Playbook: 30/60/90

Days 1-30. Create a one-page RACI that names specific humans, not just roles. Build a complete integration inventory with named owners for each connection. Establish a weekly 30-minute SalesOps/IT sync that starts with a review of the triage board. Run Salesforce Optimizer and Security Health Check; close the top ten findings jointly. This initial sprint surfaces the most dangerous gaps—like single API users with static passwords or unowned integration endpoints—before they cause incidents.

Days 31-60. Migrate all profiles to permission set groups—this is the single most impactful change for security hygiene. Document your change pipeline: sandbox tiers (developer, sandbox, partial copy, full copy), deployment cadence (weekly for minor changes, monthly for major), and rollback procedures. Run a permission set group audit to identify any users with Modify All Data or View All Data who shouldn't have it. This phase typically finds 5-15 unauthorized admin-level grants in mid-market orgs. Also during this phase, establish a naming convention for permission set groups that makes their purpose obvious at a glance—for example, "PSG_Sales_Rep_Standard" or "PSG_Sales_Manager_Extended." This simple step reduces confusion when new team members need to understand who has what access.

Days 61-90. Establish a monthly CRM health review that covers: adoption metrics, data quality scores, integration uptime, and security findings from the previous month. Publish a runbook for the top five incident classes (integration outage, permission error, data corruption, performance degradation, security alert). Begin measuring mean time to detect (MTTD), mean time to resolve (MTTR), and deployment frequency. Report these metrics quarterly to the executive team. Organizations that complete this playbook see MTTD on security regressions drop below 24 hours and MTTR on compliance findings fall under 5 days. The monthly health review should be a 60-minute meeting with a fixed agenda: review metrics from the previous month, discuss any incidents, review the triage board, and plan the next month's priorities. The output of each review should be a one-page summary sent to both teams and their leadership.

The Decision Tree for Ownership

When a change request arrives, use this simple decision tree to determine who leads:

1. Does the change affect how revenue is recognized, forecasted, or reported? SalesOps leads.
2. Does the change affect who can access what, or how data leaves the platform? IT leads.
3. Does the change affect both? Joint architecture review, single named owner, written decision log.

This tree covers roughly 90% of CRM change requests. The remaining 10%—typically involving new integrations or custom objects—require the joint architecture review. In those cases, SalesOps writes the business requirements and IT writes the technical implementation plan, and both sign off before any work begins. The decision log becomes a critical artifact for audits, demonstrating that every CRM change had clear ownership and governance. The log should capture the date, the change request, the decision, the rationale, and the names of the decision-makers. Store this log in a shared location that both teams can access, and reference it during the weekly sync to ensure consistency.

The decision tree should be posted prominently in both teams' workspaces and included in onboarding materials for new hires. It should also be embedded in your ticketing system as a required field: when someone submits a change request, they must answer the two questions (revenue impact? security/access impact?) before the ticket can be submitted. This forces requesters to think about ownership before the ticket reaches either team, reducing the number of "who owns this?" discussions by roughly 50%.

Antipatterns and Detection Signals

Shadow admin. A non-IT employee has Modify All Data with no grant record. Detect via Setup Audit Trail and quarterly profile review. Remediate by scoping permissions to the minimum required for the role. This is the most common Tier-1 finding in mid-market SaaS audits, according to SANS guidance. Shadow admin often arises when SalesOps needs to make a quick change and IT is unavailable, so the SalesOps lead is granted full admin access "temporarily" and never revoked. To prevent this, implement a process for temporary admin access that auto-expires after 72 hours and requires re-approval from IT.

Single API user. All integrations authenticate as one named user with a static password. Detect via Login History; remediate with Connected Apps and OAuth 2.0. This antipattern creates a single point of failure for security—if that user is compromised, every integration is exposed. It also makes auditing impossible because you cannot determine which integration performed which action. Migrating to Connected Apps with OAuth 2.0 typically takes 2-4 weeks per integration but dramatically improves security posture.

Spreadsheet-as-source-of-truth. Sales managers email weekly forecast spreadsheets because they don't trust the CRM data. Detect via dashboard-vs-forecast variance. This is a leading indicator that CRM ownership is broken—users are bypassing the system because they can't get what they need from it. The root cause is usually either data quality issues (which SalesOps owns) or performance issues (which IT owns). The triage board should have a dedicated column for "trust signals" that tracks any instance of spreadsheet-based workarounds.

Ticket bouncing. The same request reassigned three or more times. Detect via routing analytics; fix the RACI, not the ticket. Ticket bouncing is a symptom of unclear ownership boundaries and will persist until the RACI is updated. When you see a ticket bouncing, schedule a 15-minute meeting with both team leads to update the RACI immediately, rather than trying to route the ticket more carefully.

Silent integration drift. A vendor-side API change breaks a sync and no one notices for weeks. Detect via synthetic monitoring with a named on-call rotation. This antipattern causes data quality issues that compound over time, eroding trust in the CRM. Implement synthetic monitoring that checks each integration's health every 15 minutes and alerts the on-call person if data hasn't synced within the expected window. The on-call rotation should alternate between SalesOps and IT, with the shared tier owner acting as the escalation point for issues that cross boundaries.

Regulated-Industry Overlays

HIPAA. IT enforces PHI field-level encryption, BAA inventory, and Shield Platform Encryption. SalesOps tags PHI fields and limits exports. The handoff includes a mandatory PHI impact assessment for any field or object change. Organizations in healthcare typically add a third column to their triage board for compliance-related disputes. The PHI impact assessment should be a 5-question form that must be completed before any change to a field or object that could contain protected health information. This form is reviewed by both teams' compliance leads before the change proceeds.

GxP / life sciences. IT owns Computer System Validation, change-control evidence, and 21 CFR Part 11 e-signature configuration. SalesOps owns process documentation and training records. The change pipeline must include an audit trail that satisfies FDA requirements, which means deployment cadence is slower but more rigorous. In these environments, the handoff checklist includes an additional item: a validation summary that documents what was tested, by whom, and what the results were. This summary becomes part of the regulatory record and must be retained for the required period.

FedRAMP. Use Salesforce Government Cloud; IT owns boundary attestation; SalesOps documents data-flow diagrams to support Authority to Operate (ATO). The RACI must include a FedRAMP liaison who reviews any change that could affect the system's authorization boundary. The liaison participates in the weekly sync and has veto power over any change that could impact the ATO. Data-flow diagrams must be updated quarterly and reviewed during the monthly CRM health review.

Org-Size Scaling

Under 200 employees. One SalesOps lead and one IT admin can run this model with a written RACI and a weekly 30-minute sync. No formal Center of Excellence is needed; the two-person fusion team is the CoE. The triage board can be a simple shared document. This setup works because the communication overhead is low and both people know each other's work intimately. The risk register can be a simple spreadsheet with 5-10 rows, reviewed quarterly during the regular sync.

200-2000 employees. Stand up a formal CoE with a SalesOps Director, IT Platform Lead, Integration Engineer, and Security Architect. Quarterly architecture reviews become mandatory. The triage board should be in a shared tool with automated escalation. This is the scale where ownership ambiguity becomes expensive—the cost of a single integration outage can exceed $50,000 in lost pipeline. The CoE should meet weekly for 60 minutes, with a rotating agenda that covers the triage board, upcoming changes, and metrics review.

2000+ employees. Multi-region governance, business-unit subcommittees, dedicated DevOps engineer, vendor management office for integrations. Federation model: central CoE sets standards, business units operate within them. The RACI becomes a multi-page document with escalation paths for each region. The triage board is reviewed daily, not weekly. Each region has its own triage board, but a central board tracks cross-region issues. The CoE includes representatives from each region who attend a monthly global sync to share learnings and align on standards.

Risk Register

This risk register should be reviewed quarterly and updated as the CRM ecosystem evolves. Each risk has a named owner who is accountable for the mitigation, not just the detection. The likelihood and impact ratings are reassessed based on actual incidents from the previous quarter. When a risk is realized, the owner must document what happened, what the impact was, and what changes were made to prevent recurrence. This documentation becomes part of the institutional knowledge that feeds back into the triage board and the RACI.

Related questions

What is the minimum viable RACI for SalesOps and IT?

A one-page document naming specific humans for CRM field management, user provisioning, integration ownership, security reviews, and change approval. Reviewed quarterly and updated within 48 hours of any team change.

How do we handle CRM integrations that touch both sales and marketing?

SalesOps owns the business logic for sales-facing integrations; marketing operations owns marketing-facing integrations. IT owns the technical connection layer. A shared integration document signed by all three teams governs each connection.

What happens when SalesOps and IT disagree on a CRM change?

The change goes to the triage board with a 48-hour escalation window. If unresolved, it escalates to the VP of Revenue Operations and VP of Engineering for a 30-minute joint decision. The decision is logged for future reference.

Who owns CRM data quality and hygiene?

SalesOps owns field-level data quality—completeness, accuracy, and formatting. IT owns system-level data integrity—deduplication, backup, and recovery. The shared tier handles cross-cutting data quality dashboards and monthly health reviews.

How do we transition from IT-owned CRM to the fusion model?

Start with a 30-day audit of current ownership, then implement the one-page RACI. Begin the weekly sync immediately. Migrate profiles to permission set groups within 60 days. Full transition typically takes 90 days with measurable improvement in ticket resolution time.

FAQ

What exactly does "SalesOps owns the CRM" mean in practice? SalesOps controls all CRM fields, picklists, validation rules, page layouts, workflow rules, and approval processes related to the sales funnel. They also own the reporting dashboards, pipeline stages, and user adoption metrics. IT retains control over the underlying platform infrastructure, security settings, and system-level backups.

How do we decide who handles third-party integrations like Outreach or Gong? SalesOps owns the business logic—which fields sync, what triggers an action, and how data maps between systems. IT owns the technical connection: API keys, authentication, rate limits, and error handling. The handoff happens at the integration's data schema, with both teams signing off on a shared integration document before go-live.

What if IT wants to change a field that SalesOps relies on for forecasting? Any CRM schema change that impacts sales reports or automation must go through a joint change advisory board. SalesOps approves the business impact, IT executes the technical change, and both teams test in a sandbox before production. No field can be modified unilaterally by either team.

Who handles CRM user provisioning and deactivation? IT owns the identity management system (SSO, role-based access, license allocation) and deactivates users when they leave the company. SalesOps owns the CRM-specific role hierarchy, sharing rules, and permission sets that determine what each user can see and do within the system.

What's the typical handoff process when SalesOps needs a new custom object? SalesOps writes a requirements document specifying the object's fields, relationships, and business rules. IT reviews for technical feasibility, data model impact, and performance. Once approved, IT creates the object and exposes it via API, then SalesOps configures the user interface, validation rules, and reports.

How do we prevent the "shadow admin" problem where SalesOps bypasses IT? Establish a clear RACI matrix that names specific humans for each CRM domain, and enforce that only IT can grant system admin access. SalesOps should have delegated admin roles with scoped permissions, and any workaround requiring full admin rights must be logged and reviewed in the weekly cadence meeting.

Sources

• Salesforce Well-Architected Framework — https://architect.salesforce.com/well-architected/overview
• Salesforce Center of Excellence Decision Guide — https://architect.salesforce.com/decision-guides/coe
• Salesforce Permission Set Groups Overview — https://help.salesforce.com/s/articleView?id=sf.perm_sets_groups_overview.htm
• Salesforce Trust Site — https://trust.salesforce.com/
• NIST Cybersecurity Framework 2.0 — https://www.nist.gov/cyberframework
• ISO/IEC 27001 Standard — https://www.iso.org/standard/27001
• CIS Controls v8 — https://www.cisecurity.org/controls
• OWASP API Security Top 10 — https://owasp.org/API-Security/
• DAMA-DMBOK Data Management Body of Knowledge — https://www.dama.org/cpages/body-of-knowledge
• Gartner CRM Strategy Research — https://www.gartner.com/en/sales/insights/crm-strategy
• Forrester Wave for Sales Force Automation — https://www.forrester.com/research/
• Salesforce State of Sales Report — https://www.salesforce.com/resources/research-reports/state-of-sales/
• Microsoft Dynamics 365 Administration Documentation — https://learn.microsoft.com/en-us/power-platform/admin/admin-documentation
• HubSpot Account Security Knowledge Base — https://knowledge.hubspot.com/account-security

Related on PULSE

• [What is Sales Operations and what does the function own?](/knowledge/q12707)
• [How should a 2027 CRO and COO design their handoff on revenue operations?](/knowledge/q12476)
• [When should a 2027 company split RevOps from sales operations?](/knowledge/q12614)
• [How should a 2027 founder and COO partner on sales operations?](/knowledge/q12576)
• [How do you build a sales operations stack from scratch in 2027?](/knowledge/q12261)
• [For a founder-led org running two motions, what's the right compensation and title structure for the first dedicated deal desk hire?](/knowledge/q9532)