This is really a solution and not a problem, but there were several forum threads discussing this. We were told by more than one person in Freshdesk support that in the Garden Plan it was not possible to support Simple SSO with multiple products (websites). It took some doing (and using features that are not currently well documented) but we did get it to work.
First some background from what I learned in this process:
Freshdesk multi-product support works off of the request hostname. So,
to get multi-product support to work you create a DNS CNAME record that
points multiple (one per product) hostnames to your "default" product page (yourproduct.freshdesk.com). You will
still use https://yourproduct.freshdesk.com to get to your default
product page, but you'll use the other host names to get to your other products (you could ignore the default product as well and only use the "other" products by simply not publishing the default product hostname).
So, you can have the following organization:
product1.yourhostname.com -> yourproduct.freshdesk.com
product2.yourhostname.com -> yourproduct.freshdesk.com
etc.
Then, you will need to create an endpoint that Freshdesk can call to authenticate all of the users across all of the products. We did that by adding a page to our existing SSO server (since that is the only hostname that is shared among all of our properties, which includes the ones attached above to Freshdesk). That code validates that the user is logged in, and calls back to the hostname with signed data validating the current user. To clarify this I have published a GIST with the relevant code.
It is vital that your new login endpoint redirect the user back to the original hostname that was used. This is passed in the URL to your endpoint as host_url (which is badly named since it actually contains the host name from the original request, not a URL). The reason you must return the user to the same host name is to allow it to create auth cookies specifically for that domain. It's important to note the side-effect of this that they are only logged into that one product's domain, they still require login to any other products, but the user shouldn't see anything special as long as users are already logged into your website (hence your SSO) before clicking on a link for support.
From a security standpoint it must be said that since they are piggy-backing off of your primary domain, they have access to all of your, otherwise private, cookies. Of course, since these cookies are stored in the client browser anyway, you shouldn't have put any private data in them anyway (it should be in the session). But it's good to understand the limitations/side-effects of this implementation.
Here is a GIST that I have created with the running code from our solution (at least, as of writing this post).