Welcome to the Gainsight Community

Introduction: Hey everyone! I'm excited to share our journey in automating our end-to-end process for self-adoption assessments and scorecard updates. This initiative has significantly improved our efficiency and accuracy, and I believe our learnings can help you too! We've streamlined everything from survey delivery to scorecard updates, and I'm going to walk you through how we did it. Our Automated Process: An Overview Our automated process has several key steps: Survey Creation and Delivery: We kick things off by creating and delivering surveys to our customers. Survey Completion: Once the customer completes the survey, the process moves forward. Backend Data Management: This is where we handle the data behind the scenes. Manual Intervention (as needed): For our high-touch customers, we've built in a step for manual intervention to ensure accuracy. Automation Engine: The rules and logic that drive the automation. Scorecard Updates: Finally, updating the scorecards within Relationship 360. Delivery Methods: High Touch vs. Low Touch Like many of you, we have different service delivery methods: Scaled Method (Low Touch/No Touch): For these customers, we use Gainsight Journey Orchestrator to send surveys with an initial invite and a reminder. High Touch Method: Here, CSMs have more control. A CTA is triggered, allowing them to decide when and how to deliver the survey through email assist tasks within the playbook. This gives them the ability to target specific contacts and personalize their communication to better align to their current customer engagements. Key Tip: We built the survey at the Relationship level which is how we have our Products mapped in Gainsight. Thus the contacts that will be used in either delivery method need to be in the Relationship Person object. Internal Notifications and Survey Responses Once a survey is completed, we have a JO program to send internal notifications to our team with a link to the survey response. This allows the CSM to view the entire survey response, including who completed the survey, for which company and product, and provides a comprehensive view of all responses. These notifications also include links to a Wiki site with process details, next steps, and best practices, as well as a link to the survey response itself. Data Management: The Backbone Data management is crucial! Here are some of the ways we handled it: Low Volume Object: We used a low volume object to mirror the survey design and allow for editable fields. This provides flexibility for managing updates. These objects are also used to create reports. Custom R360 Layout: We created a custom R360 layout so CSMs can easily see adoption assessment results and related reports, specific to the product. Key Tip: This step is only needed because we wanted to add the next step for manual intervention in our high-touch accounts. Manual Intervention: Ensuring Accuracy We recognized that high-touch customers often have complex organizations, and survey respondents may not always have a complete understanding of every product feature. To address this, we built in a manual intervention step that allows CSMs to modify survey results without altering the original survey data. By default, all survey responses are included, but CSMs can exclude entire responses or modify answers to specific questions. Real-World Example: We had a customer who answered "yes" to using a feature, but the CSM knew they weren't. The manual intervention step allowed the CSM to correct this, ensuring accurate scorecard calculations. Automation Engine: Keeping It Running The automation engine is what keeps the whole process running smoothly. Data Designer: We use a data designer to create weighted averages for each product feature, based on the survey results. Rules Engine: We created a multi-step rule chain to automate the process; the first rule focuses on populating our low volume object from our initial set of survey data and the second rule takes the calculations defined in our data designer and applies them to the data within our low volume object, loading the results to the Relationship scorecard measures. Scorecard Updates: The Final Step The rule that loads the scorecard measure runs weekly so there may be a delay if a manual override is updated. To maintain transparency and provide valuable context, each update triggers a detailed timeline entry, explaining the reason for the change and the contributing average response. This clear audit trail empowers our CSMs with a comprehensive understanding of the data driving the scorecard. Key Takeaways: Automation can significantly streamline self-adoption assessments and scorecard updates. Providing options for both low-touch and high-touch customers is essential. Manual intervention capabilities are crucial for ensuring data accuracy, especially with complex customers. Gainsight’s low volume objects, data designer, and rules engine are powerful tools for building this type of automation. I hope this overview is helpful! I'm happy to answer any questions you have.

Summary: Summary: This article provides a comprehensive guide to planning, launching, and managing Gainsight Journey Orchestrator (JO) programs, emphasizing thorough planning, testing, and communication. It should take approximately 10-15 minutes to read thoroughly. Missed the previous posts in this JO-focused series? This article follows these previous posts: Understanding Journey Orchestrator: Yes, it’s important enough to have its OWN admin! Diving Deep: My Role as a Gainsight JO Admin Main text: Getting started: a good plan is essential As you plan your first few JOs, it’s best to start simple. The fewer steps and the less complex the source, the greater the likelihood of a successful launch, and the lower the risk of errors. Look for the low-hanging fruit, especially where automations can result in a big win for you and your team. Speaking of your team, include your stakeholders from the beginning — all of them. Ask questions. Skipping this crucial step is a surefire way to experience unpleasant surprises, and will likely end in failures or messy rebuilds when a stakeholder changes their mind (either before or AFTER the program launches). Some questions you might ask include: Will this email need a tokenized field in the content? Who will this communication be sent from? How frequently will the content need updates? During your kickoff conversations with stakeholders, establish a project doc — EVERY project needs a doc so nothing gets missed. Nothing complicated, and you’ll likely develop your own template over time, but it’s a good way to ensure you have all the information when you start building your JO. A good project doc will also help with the golden rule for builders (across industries): measure twice, build once . Rebuilds are messy, and there’s nothing worse than spending hours creating the source and logic for a program, only to realize that the foundation won’t meet the needs of the project. Cleanliness is next to… well, cleanliness is critical. Just like labeling code, labeling and documenting every step in your program with a clean, transparent naming convention that describes what each step does is crucial , as it allows your teammates to look at a program and understand at first glance what is happening. As your programs get more complicated, it’s easy to forget what happened three merges ago, or what’s being looked at in a conditional evaluation step. The more steps and branches your program has, the greater the necessity. This community post (see the comment from ​@matthew_lind ) offers some fantastic examples of best practices when it comes to naming conventions. Advanced JO query labels for easier reading Being able to quickly ascertain which step does what is especially helpful when it comes time to test and/or troubleshoot a program, both when you’re working with one of your teammates, and when you have to open a support ticket. If you want your Gainsight support agent to be able to help you quickly, helping them to have a clear understanding of what’s happening in your program allows them to diagnose what may be causing an issue. As you build your way through your program, always be testing — both as you build and prior to launch. Getting to the “ready to launch” phase and realizing you have to scrap your build can be a major blow to your ego. Sometimes it just happens, but if it’s preventable, it’s best to figure it out as early as possible. Key considerations – explore every angle As you plan a new JO, explore every angle. This is a key part of the kickoff conversations you should have with program stakeholders as you develop your project doc. Do you know your audience, or do you need to adjust your targeting? Is there a chance you might need to reuse the source (with updates) frequently, and in other areas, or is the source only applicable for single-run JOs? Consider whether a query, data design, or event might be the best source for your goals. Can you reuse part of the source? Consider building a data design template so you don’t have to keep rebuilding the same datasets and merges. (see this post for an example) Data Design (DD) Template building block to map string text to an email​​​ DD Template building block incorporating another building block with user info Dynamic JO design with clear labels for easy, at-a-glance understanding of journey flow Have you (and your stakeholders) fully explored the journey length (and logic)? How many emails do you want to send? How many versions (based on what criteria)? What evaluation logic will be used if there are multiple emails and versions? How long do you want the email recipients to wait between each email? Are there any actions they need to take, or should they progress through the journey automatically? What will the content look like (and who will be building it)? Will you need to use calculated fields, or does it matter if a field changes while the recipient is in the program? If you’re using calculated fields, make sure you’re tying them to the recipient/company appropriately! How long is the lifespan for the content? “Permalinks aren’t permanent” — thanks for that nugget of wisdom in Episode 96 of your Digital CX Podcast , ​@TurkOfAges ! Should participants be able to re-enter the program? If yes, how often? What is your uniqueness criteria? (Hint: recipient email address and company identifier is a good combination.) How frequently do you want your audience query to run? How will you be tracking program engagement? Simple tracking can be done within Gainsight, whether through reports and dashboards, or through a quick glance at the program analytics. If your stakeholders utilize UTMs, adding those to your links is a great way to gauge your overall JO contributions to their campaigns. If stakeholders are outside of Gainsight, systems such as DOMO allow data to be visualized in even more comprehensive dashboards. Program launch countdown When you’re getting ready to launch your program, there are several items to keep in mind (developing a checklist may help while you’re establishing your process): Confirm all necessary aspects are toggled/filled out correctly. A lot of important checkboxes, toggles, and options are scattered across a multitude of different screens and menus within JOs. (ex: Map to Timeline, participant uniqueness & re-entry criteria …) Double-check email envelope settings, CCs/copies, etc. — correct name and email addresses, spellings. Make sure email versions are mapped correctly (including logic)! Prep for analysis — make sure link(s) are tracked to allow click tracking, and UTM parameters are added if used. Test, test, and test again. Prevent unpleasant surprises AFTER launch by testing EVERYTHING. Consider: source, journey logic (evaluation steps, branching paths), email content (including templates with multiple versions, tokenized fields), subject lines, etc. Cloning your JO and creating a test version filtered to include participants meeting specific logic criteria to allow previewing every version can be very useful — if you launch a test JO, make sure to use YOUR email as the recipient! Looking for tips on testing your program? This post by ​@sarahmiracle is priceless (and timeless). Plan your launch date. Consider the best time and day of the week to launch your program — depending on the schedule, Fridays can be good to avoid sending an email to too many people. Be prepared to hit “pause” or take the program offline if needed. Communicate the launch timeline (and what will be launched). Communication is key. Use all appropriate internal channels to limit surprises. Consider whether other teams besides stakeholders might appreciate a heads up prior to launch. (ex: You’ve been working with the CSM team, but the support team might not know anything about it and could be taken by surprise.) Share the doc — make sure everyone knows what will be sent (not just the overview). Sharing the subject line and sender name is very helpful — especially if CSMs/AOs/support reps are getting customer responses. Ensure the JO participant sync schedule is set up to coordinate appropriately with the JO entry schedule. Depending on your source (ex: query that only runs once for a 1x program), you may need to sync the query prior to launch. Programs that run with multiple queries (typically Advanced JO) or are scheduled to query a data design should NOT be launched with participants in the program, unless you want emails to send as soon as the program is active. HOWEVER , the program needs to be fully active (and takes time to become active) prior to the time the source syncs. The program launch time and source sync time CANNOT be scheduled at the same time — I suggest at least a 30 minute buffer time. Post-launch followup Give yourself a hand — your program is live! After launch, it’s time to follow up to make sure things are running smoothly. First things first, check the activity to make sure participants are flowing as expected. As you monitor your metrics, it’s best to keep a relaxed frame of mind — and circulate this bit of knowledge with program stakeholders (noted in this Community post by ​@ajprince: engagement metrics and timeline/activity feed appearance can be delayed by up to 24 hours after program launch. After the first 24 hours (and subsequent reporting back to project stakeholders), if your program is scheduled to continue running on a recurring basis, it’s a good idea to add it to a recurring program log to check back on a regular timeframe to make sure nothing abnormal is happening. This is also a great place to record any program changes (query updates, reasons a program is paused/archived, etc.). Conclusion Successful program launches require careful planning, clear communication, and thorough testing. Start simple, involve everyone, and write out all the details. Label each step clearly, and test throughout the process. Pay attention to your audience, content, and how people move through the program. Before launching, double-check the settings, test again, and clearly socialize the planned launch date at least a full business day prior to activation. After launch, monitor the program and keep a log of ongoing programs for future reference. To my fellow admins, is there anything I’ve missed here that you’d recommend as a key thing to keep in mind for anyone new to JO? After three years, so much of this is just ingrained. 😆

Alright, so this is all about controlling who gets to see what in your reports and dashboards. We're gonna talk about two main things: sharing groups and folder permissions. Quick Rundown: Part 1: Sharing Groups - Making Teams: Basically, you can create your own teams of people to share stuff with. These teams can update automatically based on certain info (dynamic) or you can just pick the members yourself (static). I’m using a simple example here: CS Managers>CS Leads>CSMs. Part 2: Folder Permissions - Locking Down Folders: You can also control who can even open and see the dashboards within specific folders. Whatever rules you set on a main folder automatically apply to all the folders inside it. Each folder is shared with the right team of people (that sharing group we talked about) Part 1: Create your sharing groups Go to data permissions → sharing groups. For this example, I have 3 groups that follow this hierarchy:CS Managers CS Leads CSMs Accessing Sharing Groups The great thing about sharing groups is that you can use both dynamic and static attributes. If you have a field (or combination of fields) that you can leverage as a filter, great! But if you don’t, you’ll have to follow the custom User attribute path. In this example, I’m using a dropdown field: a) Create your dropdown list via Data Management b) Add a new Dropdown List field into the User object via Data Management, assigning the list created beforec) Populate/update the field either manually or via rules engined) Add the field as a User Attribute Data Permissions - Adding User Attributes Update your sharing groups as needed. If your field doesn’t appear as a filter, do step d. Refresh to double-check if the data makes sense, and you are ready to go! Data Permissions - Updating criteria of Sharing Groups Part 2: Managing Permissions by Folder Do you know that you can easily manage access to Dashboards at Folder Level ? Dashboard Builder folders Because the children inherit the parent’s permissions, the next bit's pretty simple.There's just one little catch: we can only go one level deep with subfolders. So, the 'CSMs' folder gets shared with all three groups, and the other subfolders just go to their own specific groups. The managers will have access to any dashboard stored into the CS Leads folder. Managing folder permissions Just store your dashboards in their corresponding folder, and you are done! I want to make sure I'm hitting all the right notes when it comes to reports and dashboards. So, what else is on your radar? Don't be shy – pop any other questions or topics you're interested in down in the comments. Let's keep the conversation going!