You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
Tyler Technologies builds public sector software solutions that connect governments to their citizens, from the data platform used for the city of Buffalo, NY’s COVID-19 response, to cyber security for the city of Auburn, Maine. When building a Knowledge-Centered Service (KCS®) platform for their ERP product support team, they turned to Confluence and Comalatech.
Tyler provides integrated software and technology services focused entirely on the public sector, serving all levels of government, from federal to municipal. These solutions cover several verticals including cyber security, appraisal and tax, and enterprise resource planning (ERP) – software that integrates different organizational activities, like accounting, customer relationship management and HR into one complete system. Tyler has been in business for decades, and grew, largely through acquisitions, to a team of 5,500. This growth is a testament to their success, but those M&A activities have also brought challenges.
@Libby Healy, Tyler’s ERP KCS Program Manager explains, “When you grow through acquisition, you get their software, their people, and their ways of managing information. Each company that comes in has its own CRM, wiki, SharePoints etc. Our focus is integrating the tech that our clients deal with, to give them one seamless experience. But we ourselves had siloed information as a result of the way we grew. That’s when we started looking at Atlassian products like Confluence as an enterprise solution, so everyone in the company can have access to information.”
As part of this effort, Libby was tasked with creating a KCS program for their ERP product support. In a nutshell, Knowledge-Centered Service is a methodology for delivering customer service that focuses on creating, sharing and reusing knowledge. The core of this program would be a knowledge base of articles that answer customer support issues, directly searchable by clients. The project scope required her to use software that Tyler Technologies already owned, and maintain a Tyler-wide focus, building something that everyone at the company could eventually use. That meant using Confluence.
At previous companies, Libby had used very templated solutions for developing KCS platforms. But with Confluence, she had free rein to create a tailor-made platform, based on the principles of good KCS methodology. Libby says, “As a tech product manager, it was like being given a huge sandbox to make whatever you want, as long as it meets the requirements.” Tyler began building the MVP about a year ago, while also planning how it could rapidly scale to meet the needs of the program.
While Confluence supplied this sandbox, there were still some requirements that could not be fulfilled with Atlassian tools alone. In order to find the add-ons that they needed, they turned to the Atlassian Community forums. That’s when someone suggested Comalatech. Libby reached out and asked if what she had in mind could be done. “The team was very open. They said we haven’t been doing that, but we could. We can work with you. One of their team members sat down with me for an hour, and even wrote code live. The project was born out of excitement to see what was possible, and a willingness to dig in, partner, and co-create the solution.”
Tyler kicked off the initial MVP phase of the platform about six months ago. In this first implementation, there is one knowledge base which supports their ERP product solution, and which exists in their internal Confluence instance. A single workflow, built with Comala Document Management and based on the principles of the KCS methodology, brings each article from creation, through multiple page states, and finally, starting this summer, made visible to clients.
This process begins when the support team captures a new issue from a client. This might be a question, point of friction, or deficit in the customer experiences. A new page is created with a standard template and workflow applied. This template contains the format of the article, with sections like “Description of Issue”, “Context”, “Cause” and “Resolution”. There is also a section for internal notes which won’t appear to the client.
The workflow begins in the WIP (Work in Progress) state. Different people from different teams will swarm the article, bringing others in and leaving comments as needed. As support and developers gather more information about the issue, the article is updated. This real-time collaboration is one of the strengths of Confluence, with some pages having as many as seven different contributors.
Once an initial resolution or workaround is found, the page state is moved to “Not Confirmed”, and everyone who has contributed to, or is following the article receives an email notification. This is another advantage of the system – everyone watches the same source of truth, and receives updates, without being overwhelmed by too many notifications.
There is group of about 80 people who can create articles, and all have ability to move an article to the “Not Confirmed” state. Once a user has been making articles for a while, and received coaching to make sure they can follow the content standards, they are added to a “Contributor” group. These users have the ability to review and approve a “Not Confirmed” article, transitioning it to a “Confirmed” state.
Two other states exist outside this publishing process, an “Internal” state for articles which are not client facing, and an “Archived” state for deprecated pages which need to be kept on record. These page states are activated by adding a label, which triggers the workflow to put them in the appropriate state.
With over 4500 articles already in the system, Tyler also needed a way to check their status at a glance. An overview page shows all the articles in a table, which state they are in, and who confirmed them.
One of the strengths of this system is that it is comprehensive without being too complex. The entire workflow was created by Libby with some support from Comalatech, “I’m not a developer but I’ve coded our solution. It’s about 100 lines. You don’t need to be an engineer. You do need to understand the markup language and that takes a bit of time, but I was able to engineer this solution without waiting for a developer. I can jump on and get the solution in real time.”
On July 1st, Tyler soft-launched the next phase of their KCS platform, adding KCS articles to existing client-facing product documentation. In order to bring their articles from their internal knowledge base to their clients, they incorporated two other Comalatech apps into their workflow, Comala Publishing and Comala Remote Publishing. Comala Publishing allows users to copy content from one space to another, while Remote Publishing copies content between instances. This expanded workflow adds a new “Published” state, which uses Comala Publishing to copy the article to another space within their internal Confluence instance. During this copy, the internal notes and other information that are not meant to be seen by the client are automatically removed. Next, Comala Remote Publishing sends the article via API to Tyler’s client-facing cloud instance. Clients can search this Confluence knowledge base thanks to a search engine called Coveo which crawls the knowledge base and surfaces the best articles.
This solution provides the customer with a seamless support experience, while keeping the internal instance separate and secure. For the knowledge workers, they only need to review the article and press “Publish” – the scrubbing and copying happens automatically thanks to the Comalatech apps.
The goal of this system is to provide easily accessible articles that directly answer client problems. “Technical documentation is great,” Libby explains, “unless you’re having a problem. It doesn’t give you solutions. We take a client question, pair it with the context, and then we write the answer. Knowledge articles might point to technical documentation, but they’re designed to get clients back into the game as quick as possible.”
“True dedication to customer success means meeting our clients where they are instead of expecting them to come to us. When a client has a question, they should be able to find an answer in a way that is easy, effortless and empowering to them – that is the goal of our client self-service program. And our agents have an amazing amount of professional pride in making this all come to fruition.”
One of the advantages of how Tyler Technologies has built their KCS system, is the data and insights that are generated. One example of this sort of insight was an area of friction that several clients had with the ERP software, which the development team had yet to address. With the new KCS knowledge base, a single page was created for the issue, and support was able to show that the article had been attached to tickets over 180 times. Since each support call takes an average of 20 minutes, it was easy to calculate the cost of this issue and make a concrete case for getting it resolved.
This insight also feeds into future product improvements. The development team is always hungry for actual feedback from clients, and that’s exactly what every KCS article is. Developers can refer to articles and see what questions clients are asking in their area, and how many times they were raised. As the knowledge base matures over time, this creates a loop in which client questions inform developer decision making.
If you’re interested in learning more about the services that Tyler Technologies offers, visit their website at tylertech.com. To find more case studies from Comalatech, visit Our Clients page. KCS® is a service mark of the Consortium for Service Innovation™