SCQH

Situation

We currently manage customer relationships and sales processes through a combination of tools, with GitHub effectively serving as our central system for tracking opportunities, alongside Gmail, Google Drive, Google Calendar, and GChat.

GitHub is used to structure and track most sales-related work. The primary repository is the sales repo, where each opportunity is represented as an issue. There are four standardized templates (existing client, RFI, RFP, and general sales ticket), which capture key information such as expected start date, contract value, opportunity type, and contact details. Issues also include task lists, guidance, and ongoing updates via comments. Deadlines and due dates are used as reminders, and issues are prioritized and organized into project boards (e.g. RFP-focused boards or priority-based sales boards). Collaboration and delegation happen by assigning issues and sharing links.

In addition to the sales repo, there is a bizdev repo intended for non-opportunity work such as internal initiatives, process improvements, or material creation, although it is currently used infrequently. Separate repositories exist for specific products. The DataHub repo follows a more automated workflow: issues are created automatically from incoming inquiries (many of which are unqualified), AI is used to assess qualification, and some automated email responses and follow-ups are triggered. This workflow is typically handled by a different team. The PortalJS-related workflow is less clearly defined; opportunities may originate there and involve client interactions or meetings, but they are only incorporated into the main sales process when manually surfaced.

Ownership of opportunities is not fixed. One person primarily monitors inbound emails and incoming requests, while RFPs and RFIs are handled by a small group (typically around three people) on a rotating or ad hoc basis. A shared lead-generation chat channel is used to surface new opportunities and coordinate ownership, with follow-up coordination happening across GChat and GitHub.

Communication with prospects is handled through Gmail, using templates stored in a shared Google document. Email subject lines are often standardized to allow basic filtering and counting of leads. Meetings are scheduled manually via Google Calendar or by sharing scheduling links (e.g. Calendly). For each opportunity, a corresponding project folder is created in Google Drive, where all related materials are stored, including meeting notes based on a standard template. Notes are captured either manually or with transcription tools such as Granola or Gemini.

After each client interaction, the relevant GitHub issue is updated with next steps and due dates. Follow-up emails, proposals, and other deliverables are prepared and sent manually. Tracking of progress and follow-up depends largely on updating issues and relying on due date reminders. There is no centralized or automated way to track client responses, inactivity, or overall opportunity status beyond these manual updates, and continued engagement often depends on the client initiating further communication rather than a structured follow-up process.

Project-related information is stored across a ProjectDB and Google Drive. Each project typically has a folder with documents (e.g. A10 documents, meeting notes, deliverables), primarily structured around project initiation and handover. The ProjectDB includes metadata such as assigned PMs and links, but it is not consistently maintained or updated as projects evolve (e.g. changes in roles, links to deployed portals). Additional context may become available later (e.g. via published case studies), but this is not systematically linked back to the original project records.

Complication

Fragmented system landscape: The current setup creates fragmentation across tools and processes, which makes it difficult to maintain a consistent and reliable view of sales activities.

No single source of truth: Information about a single opportunity is often distributed across GitHub, Gmail, Google Drive, and GChat. As updates are manual and not always consistently applied, it can be time-consuming to determine the current status or reconstruct the full context of an opportunity. This also makes onboarding into an existing opportunity or understanding its history more difficult.

Limited visibility across lead sources: Visibility is uneven across different sources of leads. Opportunities originating from DataHub and PortalJS are not consistently integrated into the main sales workflow, which limits overall awareness and tracking.

Manual follow-up management: Follow-up management is largely manual. There is no clear or systematic way to detect when a client has not responded or to determine when a follow-up is required. As a result, engagement timing is inconsistent and depends on individual judgment.

Inefficient internal coordination: Internal coordination also requires additional effort. Team members often rely on sharing links via chat to ensure visibility of tasks, as comments in GitHub alone may not be noticed in time. There is no clear mechanism to confirm that a task has been seen or acknowledged.

Unclear next steps on reminders: When reminders are triggered (e.g. due dates on issues), the next steps are not always clear or immediately actionable. Understanding what needs to be done often requires reviewing past comments, documents, or conversations, which adds overhead and slows down execution.

Inconsistent prioritization: Prioritization is difficult to assess consistently. Priority labels/categorization do not always reflect urgency or required action, and incomplete or outdated information further reduces clarity. As a result, it is possible for important items to be overlooked or delayed.

Risk of missed actions and opportunities: The system relies heavily on manual effort and coordination, which increases the risk of things slipping through the cracks. This includes missed follow-ups, delayed responses, and, in some cases, missed deadlines or opportunities such as RFPs.

Lack of reliable metrics and analytics: There is also limited ability to generate reliable metrics or analytics. Previous attempts to measure performance (e.g. counting issues or filtering emails by subject) have been inconsistent and difficult to maintain, leading to reliance on manual estimation or individual perception.

High manual effort for renewals and quotes: Operational tasks such as preparing renewals or new quotes require significant manual effort. Finding the latest relevant documents, pricing, and context across systems is time-consuming, and new documents are typically created by adapting previous ones.

Dependence on manual lead visibility: Visibility of new opportunities often depends on manual broadcasting (e.g. posting in a shared channel). Without this step, incoming leads may not reach the relevant team members in time.

Limited reuse of past work: Proposals, emails, and materials are stored but not systematically indexed or reused, leading to repeated manual effort and inconsistency.

Difficult access to project history and outcomes: When preparing RFPs or proposals, it is difficult to identify key information about past projects, such as the responsible PM or project outcomes. Existing records (e.g. ProjectDB) are not consistently up to date, and relevant information is spread across Google Drive and various documents. Project documentation is primarily structured for project initiation and handover, rather than capturing outcomes, making it time-consuming to get a clear overview or retrieve needed context.

Question

How can we establish a reliable, centralized, structured and possibly automated way to manage sales opportunities and customer interactions that improves visibility, coordination, follow-up, and reporting across the entire lifecycle (from lead to delivery and beyond)?

Hypotheses

1. Integration layer instead of replacement –> I'd start with this one

The main problem is fragmentation across tools, and integrating existing tools (GitHub, Gmail, Drive, Calendar) into a more unified workflow could solve most issues without replacing them. A lightweight CRM layered on top of existing tools (rather than replacing them) would provide structure and visibility while preserving current workflows.

2. GitHub-based system can be extended & better integrated with the other tools –> then this one

The current GitHub-based setup could be evolved into a more structured system (e.g. stricter templates, workflows, automations, integrations) without introducing a full CRM / new tool.

3. Dedicated CRM adoption –> lastly, if none of the above works –> I'd focus on this one

A dedicated CRM system (e.g. HubSpot, Salesforce, Pipedrive) would centralize data, standardize processes, and improve tracking, follow-ups, and reporting. The issue is not only sales tracking but lack of continuity across the full lifecycle (lead → project → outcome), and a solution should connect sales with delivery and project data.

Jobs to be done

1. When I return to an opportunity, I want to immediately understand what the status is and what needs to happen next, so I can act without re-reading threads, documents, or past discussions.

≥ github ✅ the only problem = it's currently highly dependent on human effort / manual updates

2. When logging into work, I want to clearly see what we have in our pipeline, who is responsible and what is the status, so I can ensure progress without chasing people across different channels.

≥ github ✅ the only problem = it's currently highly dependent on human effort / manual updates

3. When we or the client need to take action, I want follow-ups to be reliably surfaced and tracked by the system, so nothing depends on memory, manual checks, or chance.

≥ github ✅ however currently highly dependent on human effort / manual updates

4. When working on an opportunity, I want a single, consistently up-to-date view of its status, context, and history, so I can trust the information without cross-checking multiple tools or people.

≥ github ✅ the only problem = it's currently highly dependent on human effort / manual updates

5. When preparing proposals, renewals, or responses, I want to easily access accurate and complete historical context (projects, documents, pricing, outcomes), so I can work efficiently without manual searching or relying on individual memory.

≥ Google Drive? ✅ however currently highly dependent on human effort / manual updates 

6. When preparing a proposal or responding to an RFP that requires referencing past projects, I want to clearly see what actually happened in those projects (who led them, what was delivered, and what the outcomes were), so I can accurately position our experience and respond efficiently without reconstructing context manually. (not just initial documentation created at project start)

≥ Google Gemini in drive ✅ but also important to have data there..

7. When assessing performance and pipeline metrics, I want to rely on accurate and consistently captured data, so I can make decisions without manual reconstruction or guesswork.

≥ currently scripts in github 

8. When managing many opportunities, I want to clearly distinguish active ones from historical ones, so I can focus on what matters without being overwhelmed by irrelevant items.

≥ github ✅ however currently highly dependent on human effort / manual updates + cleaning the repo..

9. When engaging with a client, I want to clearly see what has already been communicated (emails, proposals, commitments), so I can follow up without digging through emails, chats, or documents.

≥ github ✅ however currently highly dependent on human effort / manual updates 

10. When new leads or opportunities arise (via email), I want them to be automatically visible and tracked in a shared system (+ notification), so they are not missed or dependent on manual broadcasting.

≥ github ✅ needs to be set up (I think this is how it works in DataHub repo)

11. When a lead reaches a stage that requires follow-up, I want the appropriate follow-up to be triggered based on its status, so I can keep momentum without relying on manual reminders or individual memory.

≥ github ✅ however currently highly dependent on human effort / manual updates

12. When referencing an existing or past project, I want to see its current status, responsible PM, and key links (e.g. data portal), so I can use up-to-date and accurate information without searching across systems or relying on others.

≥ no solution in place for this atm.

13. When managing opportunities, I want to minimize manual updates and administrative work, so I can focus on strategy and the overall direction.

≥ no solution in place for this atm