Improve the development lifecycle for engagements


Trying to do iterative development on engagements is very painful and time consuming, especially when you enable triggering them from the KC Bot. Anyone with a rudimentary exposure to software development lifecycles knows that you should never work directly on what’s in production. Since there’s no real versioning or branching support, you end up cloning active engagements and the active KC Bot, changing the audience criteria and working on the new version.

Working on the clones is also painful, as you need to constantly pause the Dev Bot or remove the engagement from it, then pause the engagement and then work on it.

 

Actually, if you have the engagement open before you pause the bot, it will keep complaining it’s being used in an active bot, even if you have since paused it. The engagement doesn’t refresh the bot’s state after every attempt to pause the engagement. The opposite happens when you work on a bot, to add an engagement. It doesn’t refresh the engagement state, when you try to enable it after previously pausing it. In both cases, you need to go back to the list of engagements or bots and reopen it. 

 

After you do all that, you hit the next snag. Preview mode is fine, but you really want to see the thing published in prod, so that coworkers without access to or knowledge of Gainsight can evaluate and provide feedback (call it QA). So you need to keep publishing changes to your dev version. The issue here is that you’re never really sure how long it will take for someone to see the new version of the bot or engagement. Sometimes it’s a few seconds, others it’s minutes and sometimes you need to clear all cookies or start a session in incognito.

 

I don’t know the internal limitations of your solution, but I do know that you need a better way to support quick iterations, probably via some kind of versioning or branching system. Perhaps that system would be combined with the ability to launch an engagement to staging, i.e. a control of which version/branch goes to staging vs which one is visible in production.

 

The FE warnings that I can’t edit X because it’s used in Y need to be replaced with an automation that protects the system, without adding unnecessary overhead to the user. e.g. when you tell me that it’s used in an active KC Bot, ask me if I want to pause the bot or remove the engagement from it, something better than the current process.

Video showing steps needed to make some simple changes when a engagement is in a KC bot.


Yes, it’s very painful to update engagements that are in a launched KC bot!