I got your point but I do not agree.
SSS's core is about:
1) threshold agreement, a sort of "tuneable cooperation enforcement" (very useful, because... what in your schema if one of the guys knowing one answer die with you in a car crash? Of course POTUS & VP never travel together by-law, but what for all of us, poor guys?
) ;2) freedom from a specific order in key/answers provisioning.
It's not about participants before-hand coordination and/or knowledge of the goal.
Here is a schema you could use:
1) create a random secret s for your AES-encoded "message for the future"
2) split s via SSS in, for example, 3 parts: s1, s2, s3
3) serialize s1, s2, s3, aka from now consider them just as bits-sequences
4) choose 3 questions q1, q2, q3 and their 3 answers a1, a2, a3 each known by your heirs
5) hash the answers obtaining h1=hash(a1), h2=hash(a2), h3=hash(a3)
6) calculate the (let me introduce a bit of fun in this sadness
) magic numbers: m1=s1 XOR h1, m2=s2 XOR h2, m3=s3 XOR h3the instruction given to each of your heir AFTER your death will be:
1) answer q_i (the question you have chosen to ask to heir i)
2) calculate h_i as hash of answer a_i
3) calculate s_i=h_i XOR m_i
4) provide s_i to a procedure which will collect all of them and then will apply SSS reconstruction of secret s
5) decode the message
Of course, for the sake of simplicity, I have omitted quorum threshold choice and one more technical stuff about s_i and h_i needing to be the same size in bits, but nothing impossible to deal with imho.
Of course you could object the after-death instruction are quite complicated, but of course they can be "web-ized" no more no less than your original program
