Generated from your build.Not typed from memory.
Every element in your event, who's responsible for it, and what it costs once the quote is confirmed. Read-only, because nothing in it was entered by hand.
THE PROBLEM
The scope of works is written last, from a stale list.
It's usually assembled the week of the event, by someone reconstructing what's on site from a quote folder and an email chain. Which means it describes the event as it was, not as it is.
Then a vendor arrives with a different understanding of what they're building, and the argument happens on the dock.
HOW IT'S BUILT
It isn't written. It's produced.
Allocate your elements to zones, assign the vendor or crew member responsible, confirm the quote — and the scope of works already exists. Every element you've built into the event appears with its owner against it and, once confirmed, its price.
Nothing is transcribed, so nothing is missed and nothing is out of date.
WHAT IT TELLS YOU
One screen, install and dismantle.
Every element in the build. Who's responsible for each one. What's confirmed and what isn't.
That last part is the one you'll use most. Two weeks out, the question isn't what's in the event — it's what's still unconfirmed, and who you need to chase.
WHY READ-ONLY
Because an editable scope of works is just another document.
If you can type into it, it can disagree with the event. This one can't. It's a view of your build, so changing the build changes it — and there's no second version living in someone's downloads folder.
“A vague brief is the biggest cause of failure on site.”
23 years in production, most of it fixing the consequences of one. Protée OS was built so the scope of works comes from the event itself, rather than someone's recollection of it.