Like many young people of my generation, I was swept away in the IT Revolution in India. I was picked by Tata Consultancy Services in 2004 and started working soon after on large IT service projects with companies in technology, pharma, and retail.
I always wondered where these projects came from. How were they conceptualized? Who drove these initiatives? What made leaders decide to spread the work across geographies, time zones, and languages? At one point I was working with a team distributed across the US, China, Australia, and Germany. How did these projects appear on the horizon — that an army of people were suddenly at work, with access to so many new systems, new ways of working, and new clients to deal with? How was this work organized, who did the planning, and how were the responsibilities split?
Stumbling into RFPs
Then I heard the word RFP being thrown about. I got curious and started spending time with the sales team who worked on different RFPs. That is when I realized: the customer sends a package — a collection of documents detailing how they want the service delivered, the parameters, the quantum of work, the reporting expectations.
This was very different from my day-to-day tasks of system administration and configuration. It really pulled me toward sales and the way RFPs were answered.
I was drafted into the RFP response team and given small assignments — collecting our capabilities, putting together CVs, writing service descriptions. Then I realized there was this thing called Proposal Presentations (or Orals) which make or break the deal. I wanted to get into those.
Thus started my journey into pre-sales and sales.
The realization
After working for more than a decade in these processes, I started feeling that the RFP process itself can be improved greatly — that there has to be a better way of sharing information between the vendor and the customer.
In essence, an RFP process is simply a process where two parties come together on the same page with respect to the requirements, price, and contractual obligations. The whole exercise is designed to move two parties closer throughout the process.
With the advances in technology in processing text, numbers, and images, I thought this process could be automated and accelerated. In other words: we can push the envelope of the sourcing process into a higher performance zone.
Why "envelope"
On the term "flight envelope": In aviation, the flight envelope refers to the operational limits of an aircraft — its speed, altitude, and maneuverability. Test pilots famously expanded these boundaries to see how far an aircraft could go without losing control. Chuck Yeager's 1947 flight in the Bell X-1, when he broke the sound barrier, is the iconic example. He didn't just fly faster — he expanded the known flight envelope of his era.
Those who have seen Top Gun might remember the line: "We're going to teach you to fly the F-14 right to the edge of the envelope, faster than you've ever flown before."
The phrase has lived elsewhere too. In procurement we talk about single envelope, double envelope, and three envelope bidding — staged processes for evaluating offers.
With the advent of AI, there is now an opportunity to push the envelope of business performance into a higher zone. This is the reason we started Nvelop.
What Nvelop is for
The name was chosen because it represents, to us, the ability to push the envelope into a higher velocity while keeping the stability intact — which is what most business initiatives are really about. Businesses want to grow. Projects need to succeed. Collaboration needs to work seamlessly toward one common goal.
We envision Nvelop as the platform that makes it happen.
