Skip to main content

Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings

10000 Ideas

phaneendhar_lingam
phaneendhar_lingamContributor ⭐️⭐️⭐️

History Tracking for MDA ObjectsParked

History tracking data is important for trend analysis/ forecasting. But, there could be some objects where we are required to maintain just the snapshot data. For example in standard objects like Company/ User or any custom objects – In Company, when did the CSM change or what was the previous ARR? As of today, we do not have the luxury of keeping historic changes in Gainsight but with the help of rules/ objects we can still accomplish this. For demonstration – I’ve created the object ‘Kite Info’, which is loaded around 7am daily. Schema as follows, { * Kite Id (String) ; Kite Name (String); Kite Date (Date); Kite Value (Number); Kite Location (String) } *Kite Id is the identifier field. I’ve created a backup object that has only those fields which require history tracking(along with the Identifier) – ‘Kite Info Bkp’. This object is loaded 10am daily. But, for the first time – data from ‘Kite Info’ is loaded once ‘Kite Info Bkp’ is created. { * Kite Id (String) ; Kite Date (Date) ; Kite Value (Number) ; Kite Location (String) } *Kite Name is consistent hence not required for tracking. Rule Name -> ‘Load Kite Info Backup’, scheduled to run at 10am Load all the values from ‘Kite Info’ to ‘Kite Info Bkp’ with Upsert operation and Identifier ‘Kite Id’ History Tracking object – ‘Kite Info History’ Column Name DataType Kite Id String Kite Date New Date Kite Date Old Date Kite Value New Number Kite Value Old Number Kite Location New String Kite Location Old String Kite Date Changed Boolean Kite Value Changed Boolean Kite Location Changed Boolean Changed Date Date History Tracking Rule Setup, Rule Name à ‘Kite History Tracking’ ; Scheduled to run at 9am daily. “Timing of this rule is of highest importance – this should be scheduled to run after the source ‘Kite Info’ is reloaded but before the backup object ‘Kite Info Backup’ is refreshed. In the Merge task, I’m doing inner join on Kite Id. Fields in the Transformation task ‘Change Capture’ are as follows, Those with prefix ‘new’ are from ‘Kite Info’ Those with prefix ‘old’ are from ‘Kite Info Bkp’ Field List – Kite Id, Kite Date Old, Kite Date New, Kite Date Changed and similarly for Kite Value and Kite Location Case statement, When ‘Kite Value New’ not equals ‘Kite Value Old’ then ‘Kite Value Changed’ is True Similarly for Kite Date and Kite Location. I’m introducing another case field as, When ‘Kite Value New’ not equals ‘Kite Value Old’ (OR) ‘Kite Date New’ not equals ‘Kite Date Old’ (OR) ‘Kite Location New’ not equals ‘Kite Location Old’ Then ‘Changes Made’ is True Only if the above value true, a record will be considered for inserting into History tracking object. Loading into History Tracking object is of INSERT type action, as we have to capture all the changes being done.

Molly.McQ
Molly.McQHelper ⭐️

Filter Team Effort Criteria by Customer TierNew Idea

We're requesting Staircase functionality that enables admin users to filter and analyze Team Effort metrics (e.g., email effort in minutes, chat effort in minutes, ticket effort in minutes, etc.) by customer tier or segment. As we know, not all customers are the same. Different tiers of customers can have varying needs, expectations, and engagement models. For example, a digital or tech-touch customer may require more (or less) time and effort per interaction due to limited historical context, lack of a dedicated CSM, or simply differing expectations. In contrast, strategic, high-touch accounts typically have dedicated CSMs who are deeply familiar with the account and are, therefore, generally able to work more efficiently and strategically. A uniform approach to measuring effort can lead to misinterpretation of resource utilization and team performance. In comparison, filtering by tier allows for more accurate benchmarking, smarter resourcing decisions, and clearer operational insights. Ultimately, customer needs and expectations can vary greatly and our evaluation tools should reflect that reality. This variability in customer needs and CSM familiarity/expectations creates meaningful differences in how we internally define and measure “effort.” A single benchmark across all customers fails to account for the nuance in how different types of accounts should be served. To address this, we recommend enabling filtering and segmentation of team effort data, broken out by interaction type (e.g., email, chat, tickets), based on customer tier, segment, or other relevant classifications/filters. This functionality would allow Staircase users to evaluate effort in context and ensure teams are assessed accurately based on the customer profiles they support. Here are some key benefits that come to mind, but I am sure there are more to consider: Improved clarity on how effort varies across customer types more equitable and informed performance evaluation of CSMs and pooled support teams Better identification of where additional enablement or automation may be needed (especially for digital or low/tech-touch segments) Reinforces a “customer first” approach by aligning effort metrics with actual customer needs.

ajprince
ajprinceContributor ⭐️⭐️⭐️⭐️

Staircase - Domains associated to Multiple AccountsNew Idea

We need the option to allow specific domains to be configured to multiple accounts within Staircase. This is the current error message we receive when trying to do so: Use case: As I’m sure most Gainsight customers will have, we have customers with multiple company records (i.e. sites/locations within a global entity) and so there will be contact records that span multiple company records along with it--this is precisely what the differentiation between the Person and Company Person record is intended for in Gainsight. Staircase doesn’t handle this type of situation well today, because it has to have unique domains linked to an account record, they cannot be shared. This causes the following issues for us: It may be incorrectly associating communications to the wrong account, or just not linking them to the correct one in Staircase, and ​​​​​ This causes AI summaries from Staircase to be not posted to the correct Timeline in Gainsight (or missing from the correct one) Gainsight Healthscore dependencies on Timeline/Engagement data is then also not properly representing the meetings CSMs are having Ideally we would be able to associate domains to multiple account records in Staircase, and have the timeline entries be linked using the “associated records” feature, to all applicable Company Records in Gainsight so that timeline is updated across all relevant accounts.