And on a client program last month, we pushed hourly propensity scores from Snowflake into Genesys Cloud CX to drive pacing, right-party routing, and recycle logic, and saw an 11% RPC lift and 9% cost drop in 14 days. If you’ve done similar, did you keep logic native to the dialer or externalize it to a rules engine (Pega or a lightweight Lambda) to speed up test-and-learn?
We kept pacing native but externalized routing/recycle via a lightweight Lambda that returns a “next-best” and priority to Genesys through Data Actions (Genesys Cloud Developer Center); we toggle tests by editing a JSON in S3, no redeploys. Just watch API quotas and add a 5‑minute cache, or the dialer will chug like it’s calling through a straw. Was hourly granularity enough for you, or did faster updates move RPC?
Quick tip: we externalized the “next-best” logic but kept the rule config in SSM Parameter Store with a version flag, so the Lambda can swap variants without redeploy and return priority/tags via Genesys Data Actions; we also attach a 15‑min TTL to the Snowflake score to avoid stale recycles. Small caveat: watch Lambda cold starts — provisioned concurrency helps Configuring provisioned concurrency for a function - AWS Lambda.
Ran ‘hourly propensity’ from Snowflake; used LaunchDarkly to flip pacing variants live. Did the 11% persist?
Kept pacing in Genesys, but we pushed recycle and caller‑ID pool selection to a tiny service with an effective‑dated config table so ops can flip variants on the hour without a deploy, and we batch writes to stay under API caps. In my runs, hourly was overkill except for the top propensity band — we update those every 30 min and the rest daily to cut noise. Did your “11% RPC lift in 14 days” hold once you froze lower bands for the day?