Where I’ve seen customers do similar, the key to responsiveness has been to create a new Action to perform the installation, rather than changing a file or registry key to trigger a Policy Action for the installation.
The reason for that lies not in the “client responsiveness”, but in the client evaluation loop.
The BigFix client uses an Evaluation Loop to constantly re-check all content for applicability. Each Fixlet, Open Action, Computer Group, etc. has its content re-evaluated as part of the loop.
New content, such as a newly-created Fixlet, Action, etc. takes priority and is moved to the “front of the loop”. Once the initial evaluation is complete, this content takes its normal place in the loop.
You can check how long your client’s loop is, on average, by checking
average duration of evaluationcycle of client . This returns the average time of the last ten cycles. Times between fifteen and thirty minutes are entirely normal; I’ve seen upwards of two hours, depending on the CPU throttling and how much content is enabled in the deployment (activated Analyses, subscribed Sites, etc.)
So, if you have a file or registry key that makes your Policy Action for the installation Relevant, you can expect the client to evaluate that very quickly - the first time. But when you change that file/value later, you have to wait for that fixlet to come back into context in the evaluation loop before the action could be triggered again.
Your best option is to have your self-service store create a new Action on-the-fly, likely using the REST API. Since this is a “New Action”, it will take priority in the evaluation loop and you can get started in seconds.
Your other option is to try to reduce the time of the client evaluation loop. Increasing the CPU throttle value is a start, but you will likely make much more headway by reducing the total number of Actions, reducing Analysis Activations, reducing the number of Subscribed Sites, and improving the efficiency of any custom properties and relevance clauses.