It probably depends on the size and scope of your company/customer base, but we definitely have separate teams that admin each application. We use Salesforce for support as well as Sales - IT has a group of Business Analysts that are split across Service Cloud/Sales Cloud platforms - and we have a separate admin team in the Customer Success organization that manages Gainsight. We use Articulate for training. In my experience, you need dedicated resources for the various platforms if you want the expertise in each area and if you don't want to overload/burn out your resources. We don't have one "CRM Manager" - we work cohesively with the other teams where appropriate (although we all are governed by the same security requirements/team.) The tools only overlap in specific areas. Aside from that they function rather independently with disparate use cases.

---

Thanks for the insight Jeff. Do your admins for each application report into the overall Manager of that area (Sales manager for sales admins for example), or do your admin team report into an admin / technical manager within that area?

---

It varies. The IT BA's for Salesforce report to an IT Manager specifically for the SF platform. The Gainsight admins report to Customer Success Operations director. Articulate admin/training coordinator reports to Training manager.

---

Thanks again Jeff, that seems to be kind of in line with the direction we are most likely to take.

---

My company has an Enterprise Applications team so we do not have Admins that sit in each functional area of the business (Sales, CS, HR, Eng etc.) We have some application analysts that work across multiple systems and are more broad in scope but we also have our specialists that focus on one (SFDC Admins and Developers). Hope this helps!

---

A classic CS Ops question, Faelan 🙂 Not that that means there's a single cut-and-dry answer!





My point of view is that the true driver of the org structure here is that business expertise can be more relevant than technical expertise. That is, some of the greatest value that this kind of person can add is to be the semi-technical, semi-strategic sounding board for a business leader. When a VP of CS says, "We should be sending out surveys at the end of onboarding," for example, they then want to walk away from that conversation and have someone figure it out. But that's not something an admin can simply build. They need to be able to ask thoughtful business questions founded in an underlying knowledge of CS, like "Should we use CSAT, NPS, or something else?" or "We would need to start recording our customer contact roles reliably so we know who to send the survey to. Here are the options for that, which have both technical and process implications, and their pros and cons." So, that drives CS Ops to typically sit within CS. Plus, it makes CS into masters of their own destiny: they don't sit around waiting for a separate team to execute on their top priority, while that other team bears the burden of Sales, CS, Marketing, Support, etc. breathing down their necks 24/7 :-)





At the same time, you bring up a great point about technical expertise, cohesion, and best practices. We have a cross-functional group run by IT (cc @karl_mosgofian), which includes all system administrators, so we can keep improvements in lockstep and identify projects where they should be helping each other. It could also be a forum to develop common practices for release processes, change management, etc. Strong, thoughtful IT organizations are rockstars at exactly that kind of work.

---

Thanks for your input Joe, I appreciate it.

---

Thanks for your thoughts Seth, your point about needing someone to be a semi-technical, semi-strategic sounding board for a business leader resonates alot with me. I think in my organisation at least there is a lack of understanding at this point for the amount of time and problem solving it takes into implementing something that from the outside appears quite simple and that is where admins might struggle.

---

There are a lot of different approaches that can work, from a completely centralized IT led Applications Management team (typical in large, mature companies) to a completely federated model where every department does their own thing. Most companies are somewhere in between, with some functions in the business groups but at least some coordination provided by a central IT function. One reason is the cross functional nature of applications - if something is used only in one group they may be able to administrate it themselves but if it's used by multiple teams it may help to have a single management point. As Seth mentioned, at Gainsight we are quite federated but I lead a team that helps coordinate everyone. I wrote a blog post that goes into more detail on what we have done. However as enterprises grow in complexity, the need for some central expertise (not just in the individual applications but in managing application admins, and in how to manage shared applications and/or business processes that span different applications), and a growth path for admins (who may get bored and leave, where you might rather rotate them to another application but keep them in the company) becomes greater so don't be surprised if you experience those growth pangs and need to look a more enterprise approach to Applications Management.

---

Thank you for your insight on this Karl, that was an interesting read.

---