At TISCO, explaining the idea for an insurance chatbot was not enough to win support. People could hear the concept without having a useful way to judge what it would be like.
Our team built working prototypes in our own time. We demonstrated them to management committee members and business-unit heads before preparing the formal proposal.
The prototype gave us something concrete to discuss. It also helped us discover who was interested enough to support the work before asking the organization to approve it.
Make the uncertain part visible
A proposal has to describe a future that does not exist yet. When the experience itself is unfamiliar, both the writer and the reader can use the same words while imagining different products.
A working prototype reduces some of that ambiguity. The person watching can see what happens after an input, follow the flow, and decide whether the concept is worth taking further. The conversation can become specific enough to be useful.
That was the value of our demonstrations. We were no longer relying entirely on an explanation of what a chatbot might do. We had something people could experience and respond to.
I do not take that to mean a prototype settles the business case. It can make an experience understandable while leaving substantial questions about delivery, operation, and support unanswered. Knowing which uncertainty it resolves is part of using it well.
Find sponsorship before polishing the paperwork
Showing the prototypes to management committee members and business-unit heads helped us understand where support existed. That mattered before the formal proposal, because a proposal needs people prepared to help carry it forward.
A positive reaction in a demonstration is not the same as a commitment. I want to understand whether someone sees enough value to take part in the next decision, and whether the work fits a problem their part of the business actually needs to solve.
The formal proposal still had a job. It was where the work needed to be considered for approval. The prototype made that discussion more informed; it did not replace it.
This is why I would do the demonstration early. Writing a polished document before discovering whether anyone understands or supports the idea can make the document a very expensive way to learn that the conversation was still at the concept stage.
After the demonstration
The work was approved and launched. It was followed by my promotion and requests to upgrade other business storefronts. Prototype-first work later became more common at TISCO.
I see that as a useful part of my experience there, not something I can attribute to myself alone. The prototypes were team work. Approval, launch, and the work that followed involved other people making decisions and carrying them through.
I also would not claim that building a prototype is a reliable route to a promotion or that every proposal should begin with unpaid work. That describes what we did in this instance, not a rule I would impose on a team.
Decide what the prototype needs to prove
The advice I take from this experience is to make an uncertain idea concrete enough for the right people to evaluate it. It is not permission to use customer data, incur spending, or make security exceptions without approval. A prototype needs a scope and a safe way to demonstrate the idea, just as any other piece of work does.
Before building one, I would write down the decision it should support and who needs to make it. Then I would choose what to demonstrate and what can remain simulated. Sometimes a sketch is enough. A working flow earns its cost when the interaction is the uncertainty. The handoff should say what remains unproven, especially where a convincing demonstration can hide an operational gap.
The paperwork is easier to write when the people involved have already seen the idea, questioned it, and decided it is worth considering.