Expanding Opportunities into a Full Pre-Project Sales Workflow

The project started as a CRM idea, but the final product shape was still Opportunities.

Proteus already had Opportunities and Proposal modules. In the old product, Opportunities were mostly used for BNB, while Proposal lived as a separate module. The CEO wanted a broader sales management tool that could cover every stage before a sale becomes a project.

That is why we called the initiative Sales Module during the work. In the product, the final name stayed as Opportunities, because before project conversion every record is still an opportunity. The design goal was to make Opportunities do more than BNB: stage management, pipeline, activities, timeline, chatter, BNB, Proposal and project conversion needed to belong to the same pre-project workflow.

This meant Proposal also needed to be unified into the sales workflow. It still kept its deeper pricing and proposal logic, but users would reach it from the Opportunity context instead of treating it as a separate module with a separate starting point.

The idea came from the CEO. I worked with him through many rounds of design, then continued refining the direction with the BA and CTO as the project moved closer to development. We also joined an interview with a client company that was already using another CRM, but still did not have the kind of pursuit tool they needed. The CEO led the conversation, and I used it to understand where a generic CRM did not fit this workflow.

The brief and notes were written after several rounds of design and CEO approval, as the product moved into development planning. I treated them as supporting documentation rather than the starting point of the design.

Opportunities needed to become more than BNB.

The old model separated BNB and Proposal work. That made sense from a system point of view, but it did not match how users think about a pursuit. A single opportunity can move from lead to RFI, RFQ, BNB, Proposal and won, while the team also manages calls, emails, key dates, client contacts, internal owners, chatter and pipeline values.

The design problem was to create a CRM style workspace without losing the existing product logic. BNB and Proposal still needed to work as their own related records, but users needed one place to understand the current state of the opportunity and what should happen next.

Decision 1/3

Make Opportunity the Container for the Whole Pursuit

One record, several connected workstreams.

I used Opportunity as the main organising layer. At the listing level, users can see opportunities across the whole pipeline, with stage summaries, estimated value, weighted pipeline, BNB state and Proposal state in one place.

At the detail level, the page keeps the most important commercial context at the top: company, stage, status, Go and Get probability, due date, contract, pipeline and weighted pipeline. Under that, users can move between Activities, Teams, Timeline and Files without leaving the Opportunity.

BNB and Proposal are not hidden, but they are no longer treated as separate starting points. They sit in the right side summary area, so users can see whether those pieces exist, what state they are in and where to continue.

Decision 2/3

Design for Sales Work as Actions, Dates and Conversation

A CRM needs to help people run the pursuit, not only store details about it.

The early versions could easily have become a large detail form. That would capture data, but it would not help a sales team understand what is happening this week.

I gave the opportunity practical working views. Activities handles calls, emails, meetings, tasks, assignees, contacts, due dates and status. Timeline gives users a visual way to map the larger phases of a pursuit, such as planning, proposal development and presentation preparation. Chatter keeps team discussion attached to the same opportunity context.

Decision 3/3

Connect BNB and Proposal Without Rebuilding Them

The old tools still mattered, but they needed a clearer home.

BNB and Proposal already had important existing flows. Pulling every detailed step into the new CRM page would make the Opportunity too heavy, and it would also create more risk for teams already using those tools.

I kept the Opportunity page as the home for context and progress. The right side summaries show BNB and Proposal information beside the user's activity or timeline work, while the detailed BNB and Proposal flows can still be opened when needed.

This was the main unification: Proposal became part of the same Opportunity journey. A team could qualify an opportunity, decide whether to bid, move into Proposal, and eventually convert a won proposal into a project without losing the original sales context.

The BNB flow also keeps the Opportunity summary visible, so users can move through qualification without losing sales context. Once BNB reaches a bid outcome, the user can progress into Proposal from the same journey.

Proposal follows the same pattern. The detailed proposal work still has its own structure, but it sits inside the Opportunity frame with the sales summary, proposal summary and conversion action close by.

The approved design is now supporting development.

Sales Module is currently in development. After the CEO approved the direction, the BA and CTO used the design as the basis for the development brief and implementation planning. The strongest outcome so far is alignment: Sales Module is no longer a loose idea for a CRM, but a defined Opportunities workflow that connects stage, pipeline, activities, timeline, chatter, BNB, Proposal and project conversion.

It also helped the team protect existing product value. BNB and Proposal can keep their core flows, while Opportunity becomes the place where sales work starts, progresses and stays visible.

This project helped me design with a founder's vision without treating it as fixed.

Working closely with the CEO meant the design changed many times. My job was not only to draw each version, but to keep clarifying the product structure underneath it. The more we iterated, the clearer the pattern became: this was not a generic CRM. It was a sales workflow for project based work, where an opportunity eventually needs to become a proposal and then a project.

That made the design more grounded. Instead of adding CRM features one by one, I focused on what the opportunity record needed to hold, what should stay in existing tools and how users would move between those pieces without losing context.