For decades Development and Operations teams worked in silos. As a result, innovation stalled and gaining a competitive edge in the marketplace grew difficult. Too much red tape slowed product development to a crawl.Today, thanks to the DevOps movement, development and operations teams work together and many of these issues have been resolved. However, one team is still left out.
Ironically, it’s Customer Service, a team dedicated to solving problems and helping customers. They file tickets in response to customer problems and service disruptions but have no visibility into the status or priority given to those issues, leaving them in a silo and without answers for the customer.
The main issue facing these teams post-DevOps movement is the lack of shared context. Customer Service teams know why customers are angry, and Dev and Ops teams know about the services they use to power apps and software. The knowledge gap occurs when Customer Service submits a ticket for the Dev team.
The rise of SaaS has only compounded this issue by creating silos of data as well. According to a recent study, 73% of companies today say they will be running solely on SaaS applications by the year 2020*. SaaS apps are great but can leave important data locked away from those who need it to make informed decisions. For example, Customer Service likely uses one ITSM tool for customer service, but must use another, different tool to file bugs and issues with the Dev Team—leaving both teams without insight into the others’ experience or priority.
Customer Service is left holding the phone, wondering “when will the ticket be resolved? Will the Dev team understand how the customer’s experience is impacted? Will they treat it with the right level of urgency? Without clear communication between teams, the Support Rep can’t manage customer’s expectations or provide input to help the issue along. Meanwhile, the customer waits.
On the other hand, the Development team member (assigned to work the ticket) is looking at the issue only through the lense of the service it’s tied to. Without context or information around the customer’s experience, they’re unempowered to increase the priority accordingly.
In an ideal scenario, the Customer Service, Dev, and Ops teams would proactively map all of their customer-facing services to the backend services that power those pieces of the application. By doing so with a visible status page, all teams can check the status of the services they provide, and the wall between Customer Service and Dev and Ops begins to crumble. Armed with more information, Customer Service can now understand the backend services more clearly and use this information to communicate more accurately with customers about open tickets, and timelines.
The root cause of these silos, whether team or data silos is a lack of visibility across teams and systems. True visibility can only be achieved when every team has access to a single source of truth—a status page—where the latest updates on incidents are recorded and shared for all to see and engage with.
Ideally, the status page is available to all teams, internal stakeholders and customers as well. Internally, team members should be able to report problems, add comments, and contribute to the solution. This process democratizes the reporting of incidents and reduces the number of duplicated reports. Likewise, if customers have access to a status page, they can go there to check on the incident status, thus reducing call volume and frustration.
A vendor-agnostic solution allows you to plug in all of the applications each team uses. This includes monitoring tools, ChatOps tools, ITSM systems, etc. Define your service definitions together, and begin a shared communication around how issues affecting these services will be handled, tearing down the walls between Customer Service, Dev and Ops once and for all.