Right. Let me show you what this looks like.
I am going to set up a client project. I will walk through each step so you can follow along on your own platform if you want to set one up in real time.
First, the project name. Name it in a way that you will recognise instantly in a list: client name, destination, and date or booking reference. You will accumulate projects over time and a clear naming convention matters from the start.
Now the project instructions. This is the layer that sits on top of your general context document. Your context document handles who you are and how you work. The project instructions handle who this client is and what this piece of work needs. I am including the client’s names, their travel style, the key preferences from the consultation, any sensitivities, the destination and dates, and the kind of output I will most often need from this project.
Next, I upload the files that are relevant to this project. The client questionnaire. The supplier briefs for the properties I am considering. Any other documents I want the tool to be able to reference when I am working inside this project.
Now watch what happens when I prompt inside this project. I am asking for a proposal opening. I have not re-briefed the tool on who these clients are, what their trip is, or what they care about. All of that is already in context from the project instructions and the uploaded documents. The output reflects all of it.
Compare that to what you would get from the same prompt in a general conversation window. Without the project context, the tool would have your voice from the context document but nothing else. The output would be generic because the input was generic. Inside the project, the output is specific because the context is specific.
That is the difference. And once you have experienced it on a real piece of work, the value is self-evident.
