Jul 29, 2024 12:59 PM
My client is a midsize construction subcontractor. I built a CRM that tracks invitations to bid on projects that my client receives from general contractors (GCs). They typically receive multiple requests to bid on a single project because multiple GCs are all bidding to win the same project. All of these GCs would use my client to perform the work, however, only 1 GC can win a particular project.
The current CRM requires the sales team to create a new record each time a GC invites my client to bid on a project. The database is set up with a company table and a contact table that are both linked to each invitation to bid. This allows me to create summary statistics like win rate / GC. There are numerous other fields for each bid opportunity like that are the same across multiple invitations to bid such as what is the physical location of the project and what type of location is the project (ex Retail building).
The team is complaining about performing duplicate data entry & updating the data multiple times as the bid process progresses when 80% of the data is the same across each of the mulitple invitations to bid on the same project. Additionally, even if they win 100% of the projects they bid, if 10 GCs requested bids from my client, only 1 GC can win the project and the corresponding summary statistics show a 10% win rate instead of a 100% win rate on that project. Furthermore, tracking the sales pipeline makes the dollar amount of outstanding bids in the pipeline look much larger than what my client could actually win because there are so many situations where my client has bid multiple times on the same project.
The team has suggested that instead of organizing the CRM so that each invitation to bid is entered as a separate record, they should enter the location once and then connect GCs to the location. This would make the physical location the main record that is tracked in the CRM instead of the invitation to bid. They argue that this would cut down on duplicate data entry and make for fewer entries to manage in the sales pipeline. I agree that these two benefits would occur from their solution.
My arguments against their proposal are: 1) Different GC's may ask for different scopes of work or have different pricing on the same project which will be hard to track & measure accurately under their proposed structure, 2) A project-centric structure could be harder to measure & track win rates by client, 3) It is actually true that they are winning 10% of the work they bid, not 100% so their preferred method of measurement is misleading.
I'm struggling with determining the best structure & how to implement it. I'm reaching out to the community to get feedback on how others have dealt with similar scenarios. Do you have suggestions for the best way to structure this type of database? Thank you!
Jul 29, 2024 02:13 PM
Do you have a [Projects] table? You can link each bid to its corresponding project. Things that don’t change across the project, like the location, go in the [Projects] table. Things that can vary from bid to bid on a project, like different scopes or pricing, go in the bid.
Data entry gets a little more difficult, but it is still doable. The main trick is identifying when two different GC’s are actually bidding for the same project when they do not share all the info with you.
Jul 30, 2024 09:58 PM
we can create a hybrid structure that balances both project-centric and GC-centric data management. This approach will reduce duplicate data entry while still allowing you to track different scopes of work and pricing per GC, ensuring accurate statistics and pipeline management.