We already have this in parts. More would be better.
An ITT is like a little, short script that gets executed when a specific Event happens. It is not unlike Filters, which help sorting our cargo bays, but better.
In a way we already have ITTTs in contracts, but it is well hidden. To give an example, I will turn a courier contract into “ITTT”.
We assume that some player, the contractee, accepted a contract containing an ITTT.
This ITTT gets executed as soon as [Contractee] adds something to the destination’s cargo bay. It got activated, waiting for execution, the moment the contractee accepted the courier contract.
If [Contractee] has status [docked] at [some station], and has [some item, or set of items] in [station’s cargo hold], then [exchange for ISK].
This is what a courier contract does.
Regular contracts are simpler:
If [Contractee] has [some item] at [some station], then [exchange for ISK].
If [station cargo hold] has [Corpse], then [move] [Corpse] to [container named “Corpses”].
Player made missions.
Imagine I want to send a noob on a journey.
Some Character accepts a contract containing an ITTT. I will not go into designing such a contract’s looks, text, etc, just the core of it That which makes it happen:
If [Contractee] [scanned] [10 distinct] [wormholes], then [give ISK].
Or maybe I want him to take a sight seeing tour:
If [Contractee] has visited [List of Systems] within  [hours], then [give ISK].
How about letting him find stuff?
All that the ITTT needs is access to the list of owned secure cans anchored in space.
If [Contractee] opens [*Secure Can “Winner”], then [give item].
If [Contractee] has [Lossmail] of [some specific Ship] containing [list of modules], then [give ISK].
Sure, for this specific thing there would need to be an easy way to set up multiple contracts. An easy way out would be having a counter in contracts, which can be accepted multiple times by individual Characters. This is beyond the scope of this and not an issue for many other forms of ITTTs.
There are so many different problems, which all can be addressed this way, that I am absolutely sure that it would be amazing to have. The possibilities are virtualky limitless and the API data already provides TONS of the stuff we would need.