Seven engines. One connected commercial system.
The core loop runs each stage from first lead to renewal or a return purchase. The enabling layers run across all of them. Start with the ones you need.
The GTM Outcome Engine50+ integrations. The systems your business runs on.
Not just the ones with a native connector. Every integration is governed and monitored as part of the engine.
All integrationsRed light, green light. Four ways a HubSpot project stalls, and what we do about each one.
Most stalled projects stall for one of the same few reasons. We’ve written down the four we see most, and what we do when each one comes up.
Red Light Green Light is how we run every implementation. A red light is a problem we’ve seen before. A green light is what we do when we see it, so the build keeps going while the problem gets sorted out.
The same four problems come up on most projects.
Bad data in the old system. A client team that can’t find the time. A brief that isn’t settled yet. Another project that has to finish first. We’ve run into each of these often enough to know what works.
So we don’t treat them as emergencies. When one turns up, we switch to the approach we’ve already agreed for it, keep the build going, and deal with the underlying problem once there’s room to.
The build never waits on the problem.
The problem
Something that will hold the project up if we let it.
What we do instead
How we keep going while that problem is being sorted out.
All four of these have happened on our projects. That’s why each one has a plan.
The four scenarios.
Bad legacy data
Legacy data with poor hygiene and inconsistency can lead to duplication and unreliable information, hampering accurate reporting and efficient data retrieval. Without a clean foundation, the project risks delays and data integrity issues.
Future ready data management
To keep the implementation on track, we’ll draw a line in the sand with legacy data and focus on future data management. By setting clear standards for new entries, we maintain data quality moving forward while gradually addressing legacy issues without delaying the project.
Project stalled due to client bandwidth
The client’s limited availability prevents essential progress, creating delays that jeopardise the project timeline and outcomes. Without dedicated client input, capturing accurate requirements and addressing issues becomes challenging.
Prioritised phased engagement
We’ll maintain momentum with a Prioritised Phased Engagement approach, focusing on core milestones with lighter client involvement. Incremental, manageable steps minimise demands on the client’s team while maintaining project health until they’re ready to fully re-engage.
Unclear client vision
When a client is uncertain about their needs and unable to articulate goals, the project risks becoming directionless. Without clarity, defining requirements and aligning deliverables is difficult, which can lead to misaligned outcomes and extended timelines.
Kongo led strategic guidance
Kongo steps in to provide leadership, presenting best practices tailored to the client’s specific business model. By proactively guiding discussions and showcasing strategic solutions, we help the client clarify their vision and align on actionable goals, ensuring a focused and impactful project.
Implementation stalled by dependent project delays
When a HubSpot implementation is reliant on a parallel project that encounters delays, progress halts. This can create a ripple effect, delaying timelines and risking project momentum, potentially leading to resource misallocation and increased costs.
Reset MVP focus
To overcome the stall, we’ll reset our focus on a Minimum Viable Product (MVP) approach. By identifying and prioritising essential features that can be implemented independently, we maintain progress, deliver immediate value, and keep the project moving forward while waiting for dependent elements to be resolved.
Where this shows up during a project.
We go through all four at kick-off.
Before the build starts we walk the client through the four scenarios, so if one comes up later nobody is hearing about it for the first time.
We say so in the sprint review.
If a project has hit one of these, we raise it in the next sprint review and propose the green light approach there, along with what changes in scope or timing.
We come back to the problem.
The underlying problem stays on the list. When there’s capacity to fix it properly, we do, and fold the result back into the build.