HOW WE WORK TOGETHER

Most consulting produces recommendations. This engagement produces resolution. I work directly alongside your Revenue Operations team. I join the people already responsible for your systems and guide them through the complexity of diagnosing, understanding, and resolving the problems you're facing. Your team does the work and owns every outcome. My role is to provide the diagnostic perspective, pattern matching, systems experience and directional guidance that makes that work faster, more accurate, and more durable

  • At the start of each engagement we define and agree the working group. These are the specific people from your team who will work directly with me throughout the engagement. The group is capped at a maximum of eight people. Knowledge transfer only works at a scale where everyone can meaningfully participate. Beyond eight, sessions become unwieldy and the shared understanding the model depends on is more difficult to develop.

    The working group is drawn primarily from your Revenue Operations function, the analysts, process owners, subject matter experts and data stewards responsible for the systems in scope, but can also include IT owners and an engagement sponsor. Not sales reps, not marketers, not territory admins. Those people experience the symptoms of the problems being diagnosed. They may be called upon to provide information or comment on their experience but they are not part of the core team. The working group are the direct recipients of the knowledge transfer, they learn by doing. They work through the diagnostic process alongside myself.

  • These sessions are where the bulk of the work gets done. During an engagement every session is pre-defined, the agenda for the session is agreed in advance. That time is focused on work that genuinely requires my presence: investigation, diagnosis, interpretation, decision-making. Work your team can do independently, such as pulling data, running queries, and documenting findings, happens between sessions not during them.

    What happens inside a session depends on what the work requires. Some sessions are live investigative work: data on screen, queries running, threads followed and discussed in real time as we trace symptoms back to their structural source. Others are review sessions: your team has worked between sessions and brings findings back for me to challenge, stress-test, and help interpret. Both are valid. The session follows the need, not a fixed script.

    Sessions follow where the data leads. When a new thread surfaces that is worth pursuing but would pull the session off course, it gets noted and agreed as a topic for a future session. A session may resolve a problem completely, or it may produce clarity on what needs to be investigated next. Both are valid outcomes. Your team maintains a log of agreed decisions and next steps from each session.

  • I am a guide through complexity, helping your team navigate problems that are difficult to see clearly from the inside and transferring the diagnostic capability to them as we work. I direct the diagnostic, provide structural perspective, guide the design of solutions, and review the artifacts that your team produces.

    All project documentation and artifacts belong to and are produced by your team. I do not implement changes or execute configuration work. My role is purely advisory.

  • All working sessions take place remotely as standard. On-site visits are available for clients who want them, typically two to three days at the start of an intensive engagement or at other critical points in the project, and can be funded from a pre-purchased time block.

WHAT YOU BRING

This is a working relationship. Getting the most from it requires your team to come prepared and stay engaged between sessions. Here is what a productive engagement requires from your side.

  • The working group needs to include the people who understand and can access the systems in scope: Revenue Operations analysts, data stewards, IT owners and an engagement sponsor with the authority to make decisions and unblock access when needed. These are the people who are the direct recipients of the knowledge transfer. The working group is defined at the start of the engagement and, excepting where necessary, stays consistent throughout. Changing it mid-engagement disrupts the shared understanding the model depends on.

  • Diagnosing CRM system problems requires access to the data as it actually exists in the production system. This means the application base tables that the CRM user interface is built on. This access is held and executed by your IT or RevOps team members in the working group, not by me directly. I direct the queries. Your team runs them.

    This matters for three reasons. First, the UI your employees use is built on base table data, not on warehouse or ETL-processed data. Second, ETL processes transform data before it reaches a warehouse, which can mask the very problems being diagnosed. Third, diagnosis requires the ability to create test data/transactions and verify the result immediately, not after a four-hour ETL cycle has run. Base table access makes that possible.

    If base table query access cannot be provided, the scope, timeline, and expected outcomes of the engagement need to be discussed during scoping. Diagnosis is not impossible without it, but it is more difficult, slower and less accurate.

  • The diagnostic starts with the symptoms you can demonstrate, not just describe. Before the engagement begins your working group should be able to show, in data, what the system is producing that it should not be. The data is the starting point. The diagnostic effort works backwards from it to map and understand the data journey.

  • Sessions are for work that requires both of us; investigation, diagnosis, interpretation, decision-making. The work your team can do independently happens between sessions. An engagement where the working group only engages during sessions will take longer and produce less. The model works best when your team treats the between-session work as part of the engagement, not as optional preparation.

Book a Discovery call

FREQUENTLY ASKED QUESTIONS

  • It depends entirely on the scope and complexity of the problem being diagnosed. Some problems are contained and resolve quickly. Others span multiple systems or functions and take considerably longer. Some issues that look complex may turn out to be simple, others that look simple may turn out to be complex. There is no standard engagement length.

    Scope and expected duration are agreed mutually at the start of the engagement and revisited as the work progresses. A 30-minute sponsor review meeting is held at regular intervals throughout. This is where the engagement sponsor and I assess whether the engagement is continuing to deliver value, review the subscription level in use, and agree any adjustments to session frequency or hours required going forward. The engagement runs for as long as it is delivering value and no longer.

  • Sessions are used across all engagement types, including the CRM System Diagnostic and all subscription tiers. There is no fixed number or frequency. Sessions are flexible and structured around what the work requires at any given point in the engagement.

    For subscription clients, the hours available each month can be used in any format that works for both parties. A Full subscription provides 16 hours per month. Those hours can be used as sixteen one-hour sessions, eight two-hour sessions, four four-hour sessions, or any other combination that fits the work. If the monthly hours are exhausted before the end of the month and additional time is needed, clients can purchase a ten-hour block for the remainder of that month. The maximum available in any single month is 26 hours as standard, being the subscription allocation plus one additional block. Exceptions to this can be discussed based on availability.

    During active diagnostic phases sessions tend to be more frequent. During periods where the team is working independently or waiting for changes to move through development and patching cycles the cadence naturally reduces. Every session is pre-defined and agreed in advance. There are no standing calls that exist just to fill the calendar.

  • Base table access is a methodological requirement, not a preference. There are two specific reasons it matters beyond general data access.

    First, the base tables hold data in its original, unprocessed form. ETL processes transform data before it reaches a warehouse. That transformation can alter or mask the very problems being diagnosed. What looks correct in the warehouse may be incorrect at source. Diagnosis requires seeing the data before transformation, not after.

    Second, base table access allows test transactions to be verified immediately. Without it, every test requires waiting for an ETL cycle to run before the result can be checked. In a diagnostic engagement, that delay compounds across every investigation thread and significantly slows the work.

    If base table access cannot be provided, the scope, timeline, and expected outcomes of the engagement need to be discussed and adjusted before work begins. Diagnosis without base table access is possible but it is more difficult, slower and less accurate.

  • The engagement sponsor does not need to attend every session. Their role is to provide organizational authority when it is needed: unblocking access to systems or data, making decisions that the working group cannot make independently, and ensuring the engagement has the internal support it needs to progress.

    In addition, a 30-minute sponsor review meeting takes place weekly or bi-weekly throughout the engagement. This is a short, focused check-in where the sponsor confirms that the engagement is continuing to deliver value, reviews and adjusts the subscription level or session hours if needed, and agrees any changes to session frequency or structure going forward.

    A sponsor who is available when needed and engaged in the regular review meeting is the right model. A sponsor who is disengaged entirely will slow the engagement down.

  • An engagement is complete when the scoped problem has been diagnosed to its root cause and the path to resolution is clear and understood by the team. Where production changes are required, the ideal end point is verification of those changes in the live system. In practice this depends on the client's patching and release cycle. Where production changes are waiting to be applied, the engagement typically transitions to a lower subscription level to maintain continuity and advisory coverage through to final verification, rather than closing prematurely.

    The working group signs off on the findings and the resolution. There is no ambiguity about when the work is done because the scope and the definition of done are agreed at the start.