I may explain things a bit strange as it seems right in my head but not to others so:
You very rarely need to use switches unless you want something to spawn, only when the quest is accepted.
I will attach another image of what the script side of things is so it might help and be less intimidating (it was for me at first but I feel comfortable with it now!)
So lets take a look at the script attached.
The quest ID is :gnak (needs to be unique for each quest you create and use)
:qgivername (is what shows the source of the quest on the quest window)
:location (location of where you got the quest, fill as needed)
:desc (shows desc in quest window also)
Objectives

bjective1 (give these unique names for the quest, so there are no conflicts)
you set all your quest stuff in the script and use the :questid to reference to it.
so in the above, you can see me using the script call for ask_accept

gnak)
This basically pulls all the information you have put into the script for you.
For the others again just reference the questID but you use conditional branches to check if the quests are accepted / done e.c.t..
And if you look on my "Gnak" event you can see how to forward the objectives by using adv_obj

questid,

bjectiveid) then the amount you want to increase it by!
Again, I would see what I have typed and be a bit hesitant, If you want me to I can create a demo with a quest that works fully in there, and you can see how it works yourself? (if it will help!

)
It does seem a bit overwhelming at first, but once you get the hang of it, its a lot quicker to implement quests, a lot easier to track, and in game a lot more user friendly (they can actually see and track their quests and progress)
As the standard way need a lot more switches and people to remember what they were doing (you leave a game for a week) come back and wont remember every npc you spoke to for quests!