Loading...

Skip to main content

How AI helped me win pre-sales projects efficiently

· 8 min read
Tamás Imets
Tamás Imets
AI Solution Architect at Aliz

I work in pre-sales, which means my job is to take a client's problem and turn it into something concrete enough that they can decide to work with us. Over the last few months AI has changed how I do this quite a lot, and I wanted to write down what actually made a difference, using two projects as examples: One Hungary and VEON.

The short version is that AI made me faster, but the more interesting part is that it changed which parts of the job are actually worth the time. I will try to explain what I mean.

What changed about the work​

A lot of what I used to spend time on was building. Setting up a service, putting together a front-end, wiring things up so I could show a client what a solution might look like. That used to take a long time, and now it does not. I can build a working prototype in a fraction of the time it took before.

Because of that, building the interface itself is no longer where the value is. The valuable part now is understanding what the client actually needs, which is usually not the same as what they first ask for, and being able to turn that understanding into something they can look at and react to. If I were hiring someone for this kind of work today, I would care much more about whether they can empathise with the end user than about how deep their technical knowledge is.

This is easier to see in a real project, so let me go through the two.

One Hungary​

One Hungary is a telco that wanted to generate marketing imagery at scale. What made this project work was demos rather than documents.

The first demo I built was for an early meeting. It was not meant to be the final solution but more a way for us to think together. Showing them a working example helped them figure out what they actually wanted, which is much harder to get out of a conversation than most people expect. People react to something they can see and click on in a way they never react to a slide.

The second demo is what won us the work. I built a prototype that took one of the client's own assets and turned it into the different formats they needed, and I could show that to them directly. That was worth more than any written proposal I could have sent.

After we won the project and moved into delivery, I used the same speed to properly work out how to build the real thing. I ran the options through my architecture-brainstorm skill to settle what it takes to run it in production, where it breaks when the volume goes up, and which parts of the Google stack to use for each step. For the image generation that meant Imagen for the backgrounds, Nano Banana for keeping the product looking consistent across angles, and some custom steps for the layered output that none of the ready-made tools produce.

Each of those three stages built on the one before it, and none of it would have been possible at that pace without AI. A demo that would have taken me two weeks before, I could put in front of the client in a day or two. When it becomes that easy to show someone a real thing, you show them more, and you show them earlier, and the whole conversation becomes more honest.

Managing context​

If I had to pick the single thing that makes the biggest difference, it would not be the model itself. It would be the way I manage context.

I keep everything about a project organised in a structured way: the decisions I made, the things I tried that did not work, the research, the architecture, and the reasoning behind each choice. It is not just a pile of old chat history but something I can go back to and pull the relevant parts out of whenever I want to work on a new feature. I have a small skill for exactly this, brush-up, which pulls everything relevant about a project back into a session in one step. Because of that I almost never start from scratch. I bring in exactly the context that matters for what I am doing now, and then I add the new work back into the same place without losing what was already there.

This is the part that actually makes the speed possible. AI is only as useful as the context you give it, and the difference between a good session and a wasted one is usually whether I can hand it the right information about the project. When I do this well, each round of work builds on the last one instead of starting over, and the project gets easier to work on over time. Without it the speed disappears, because you end up spending all the time you saved explaining the project again every time you start.

VEON​

VEON was a different kind of problem. Here the value was not in a demo but in checking whether a difficult idea would actually work before we committed to it in a proposal.

VEON needed an agentic solution for their audit work, and the way it had to work was not obvious. To build it we needed to get into the backend of Gemini Enterprise and get something out of it that it does not give you easily: the chat transcripts from user sessions. The whole knowledge base feature depended on being able to do that.

Normally, working out whether something like this is possible means reading a lot of documentation and still not being sure at the end. I used my gcp-ai-research skill to get through the relevant Google documentation much faster than I could by hand, and to work out what was actually supported and what was not. Then, rather than trust the documentation on its own, I set up a new project and a fresh Gemini Enterprise instance and tried it directly. Fairly quickly I had confirmed that I could get the transcripts out, which was the key question the whole feature rested on. If it had turned out not to be possible, the architecture we were about to propose would have failed later in delivery.

What helped most was that AI took care of the slow parts, the reading and the checking, so I could spend my time on the real question, which was whether this could be done at all and, if the obvious approach did not work, what the workaround would be. That is more of a creative problem than a technical one, and it is where my time actually mattered.

Once I knew it was possible, putting the rest together was quick, because each step reuses the context from the one before. I laid out the options with architecture-brainstorm, drew the architecture with drawio-diagrams, built the effort estimate with wbs-estimate, wrote the client proposal with offering-document, and prepared the internal review with arb-review-request. None of those started from a blank page, because each one picked up what the step before it already knew about the project.

What I take from this​

None of these projects were won by AI. They were won by understanding what the client needed and showing them something real before they lost interest. What AI changed is that the expensive parts of doing that, building the demo, checking whether the hard idea works, and carrying everything I know about a project from one feature to the next, stopped being expensive.

So when people ask me which skill matters most now, my honest answer is that it is not being able to build the interface, because that part has become easy. It is understanding the person you are building for, and keeping enough context around a project that every new idea starts from everything you have already learned rather than from nothing.

Further Reading​