Skip to content
prospr GTM systems
THE DELIVERY MODEL

Discover. Design. Build. Adopt. Operate.

A GTM system should not disappear into a long implementation project. We work in visible phases, release useful improvements early, and keep the people who will use the system involved throughout the build.

Something live every week.

Done with you, not hidden from you.

DELIVERY PRINCIPLES

How we work, in six lines.

  1. 01 / 06

    Architecture before tools

    The system begins with the revenue motion, data requirements, ownership, and operating model. Software choices follow.

  2. 02 / 06

    Useful releases over a final reveal

    Work is phased so the team can test and use valuable parts of the system before the entire roadmap is complete.

  3. 03 / 06

    Users involved early

    The people who use the system participate in discovery, testing, feedback, and adoption.

  4. 04 / 06

    Decisions documented

    Important architecture, workflow, data, and ownership decisions are recorded rather than left as tribal knowledge.

  5. 05 / 06

    Adoption designed into delivery

    Training, feedback, usability, ownership, and documentation are part of the build rather than post-launch tasks.

  6. 06 / 06

    Ownership stays with the client

    The client retains access, documentation, data, workflow logic, and administrative knowledge.

FIVE-PHASE METHODOLOGY

What happens in each phase.

Each phase has a clear purpose, a defined set of activities, a decision gate, and a definition of completion. Discovery, design, and adoption are not optional add-ons.

PHASE 01 / DISCOVER

Create a shared understanding of the commercial system before proposing changes.

Questions answered

  • How does the company currently generate and manage opportunities?
  • Who owns each stage and handoff?
  • Which data is trusted?
  • Where does work happen outside the CRM?
  • Which workflows create delays or errors?
  • What does leadership need to see?
  • Which systems and dependencies exist?
  • What must improve first?

Activities

  • Stakeholder interviews
  • Revenue-process mapping
  • CRM audit
  • Data-quality review
  • Technology-stack review
  • Reporting review
  • Adoption review
  • Bottleneck analysis

Client involvement

  • Identify stakeholders
  • Provide system access
  • Share current documentation
  • Explain current process
  • Validate findings
  • Agree on success criteria

Deliverables

  • Current-state system map
  • Problem inventory
  • Risk and dependency review
  • Success criteria
  • Initial priority areas

Decision gate

Confirm what must be solved and what should remain unchanged.

Definition of completion

The current system, priorities, constraints, and success criteria are understood and agreed.

PHASE 02 / DESIGN

Turn the findings into a clear target operating model and implementation sequence.

Questions answered

  • What should the lifecycle and pipeline look like?
  • Which records and relationships are required?
  • Who owns each action?
  • Which data is mandatory?
  • Which workflows should be automated?
  • Which tools should be connected or removed?
  • How should reporting work?
  • What can be released first?

Activities

  • Revenue-architecture design
  • CRM data-model design
  • Workflow design
  • Ownership and permission design
  • Integration planning
  • Automation planning
  • Reporting design
  • Release planning

Client involvement

  • Review architecture
  • Make policy decisions
  • Confirm ownership
  • Validate terminology
  • Prioritize releases
  • Approve the implementation roadmap

Deliverables

  • Target-state architecture
  • Data model
  • Workflow specifications
  • Integration map
  • Reporting requirements
  • Release sequence
  • Implementation roadmap

Decision gate

Approve the target architecture and the first production release.

Definition of completion

The system has a documented design that the build team and client stakeholders understand.

PHASE 03 / BUILD

Turn the approved architecture into a usable production system.

Questions answered

  • Does the configuration match the design?
  • Can data move reliably?
  • Are permissions correct?
  • Do workflows trigger as expected?
  • Are exceptions visible?
  • Can users complete their work?
  • Is the data ready for launch?

Activities

  • CRM configuration
  • Data cleanup
  • Migration
  • Integration setup
  • Workflow automation
  • AI-agent implementation
  • Dashboard setup
  • Testing
  • Quality assurance
  • Documentation updates

Client involvement

  • Provide access
  • Review test releases
  • Validate data
  • Test real workflows
  • Resolve policy questions
  • Approve production releases

Deliverables

  • Production components
  • Tested workflows
  • Migrated or cleaned data
  • Integration monitoring
  • Initial dashboards
  • Updated documentation
  • Release notes

Decision gate

Approve each release for production use.

Definition of completion

Priority workflows operate correctly and users can perform the intended work.

PHASE 04 / ADOPT

Make the new system understandable, usable, and part of the team's operating behavior.

Questions answered

  • Can each role use the system confidently?
  • Are views and workflows understandable?
  • Are users avoiding parts of the process?
  • Is documentation sufficient?
  • Does the system reflect real work?
  • Who owns administration after launch?

Activities

  • Role-based training
  • Administrator training
  • User testing
  • Feedback sessions
  • Workflow refinement
  • Documentation
  • Adoption monitoring
  • Launch support

Client involvement

  • Attend training
  • Test real scenarios
  • Provide feedback
  • Reinforce agreed processes
  • Confirm internal ownership
  • Participate in launch reviews

Deliverables

  • Training sessions
  • Role-based guidance
  • Administrator documentation
  • Workflow refinements
  • Adoption findings
  • Handover materials

Decision gate

Confirm that users and administrators can operate the system.

Definition of completion

The system is in active use, ownership is clear, and critical adoption issues have been addressed.

PHASE 05 / OPERATE

Keep the system aligned with the business after launch.

Questions answered

  • Is the data staying clean?
  • Are workflows still useful?
  • Are users following the process?
  • Are new bottlenecks appearing?
  • Does reporting still reflect the business?
  • Are integrations healthy?
  • What should improve next?

Activities

  • CRM administration
  • Data-quality monitoring
  • Workflow improvements
  • Integration monitoring
  • Reporting support
  • Adoption reviews
  • Documentation updates
  • New feature releases
  • Operating-cadence support

Client involvement

  • Set priorities
  • Share business changes
  • Review system health
  • Make policy decisions
  • Participate in improvement planning

Deliverables

  • System-health reporting
  • Data-quality review
  • Workflow improvements
  • Updated documentation
  • New releases
  • Prioritized improvement backlog

Decision gate

Agree on the next operating priorities.

Definition of completion

Operate is continuous while embedded support remains active.

RESPONSIBILITIES

Clear sides of the table.

prospr responsibilities

  • Facilitate discovery
  • Design the architecture
  • Build and test the system
  • Document decisions
  • Identify risks
  • Manage delivery
  • Train users and administrators
  • Monitor agreed workflows
  • Recommend improvements
  • Communicate blockers clearly

Client responsibilities

  • Provide access
  • Identify decision-makers
  • Supply accurate process context
  • Make policy decisions
  • Review releases
  • Test workflows
  • Participate in training
  • Assign internal ownership
  • Communicate business changes
  • Reinforce agreed operating behavior

The client does not need to manage the technical build, but the system cannot be designed in isolation from the people who use and own it.

WEEKLY OPERATING CADENCE

Visible progress, clear decisions, no hidden build.

Each delivery week is structured around a working session, a shared board, a production release where dependencies allow, a feedback loop, and a written update.

  1. 01

    Working session

    • Review current priorities
    • Resolve open decisions
    • Test recent work
    • Confirm the next release
  2. 02

    Shared delivery board

    • Work in progress
    • Decisions needed
    • Risks
    • Completed releases
    • Upcoming work
  3. 03

    Production release

    • New workflow
    • Improved configuration
    • Cleaned dataset
    • Integration update
    • Documentation release
  4. 04

    Feedback loop

    • User observations
    • Adoption issues
    • Workflow friction
    • Data-quality exceptions
    • New business requirements
  5. 05

    Written update

    • What changed
    • What was tested
    • What needs a decision
    • What happens next

The exact cadence depends on engagement size and stakeholder availability. "Something live every week" is an operating preference, not an unconditional guarantee. Technical dependencies sometimes require a release to land across two cycles.

DECISION AND DOCUMENTATION MODEL

Important system decisions should not live in somebody's memory.

Significant architecture, data, workflow, and operating decisions are recorded with the same structure throughout the engagement so they remain useful long after launch.

DECISIONS WORTH RECORDING

  • Lifecycle definitions
  • Pipeline stages
  • Qualification rules
  • Ownership
  • Handoffs
  • Required fields
  • Data standards
  • Permissions
  • Workflow triggers
  • Approval steps
  • Integration ownership
  • Error handling
  • Reporting definitions
  • Administrative procedures
HANDOVER AND OWNERSHIP

Handover should be an outcome, not an emergency.

Ongoing support is optional. Ownership is not.

Ownership is transferred throughout the engagement through documentation, access, testing, administrator involvement, and recorded decisions. It should not be compressed into one final meeting.

Handover components

  • Administrative access
  • Architecture documentation
  • Data dictionary
  • Workflow documentation
  • Integration map
  • Automation inventory
  • Training materials
  • Decision log
  • Known limitations
  • Maintenance instructions
  • Improvement backlog
  • Support options
ENGAGEMENT SHAPES

Choose the shape that matches the current problem.

Audit

Primary purpose
Diagnose the current system and propose a target state.
Typical starting point
Symptoms are clear; the right scope is not.
Main activities
Workshops, audits, reviews, roadmap creation.
Client involvement
Stakeholder interviews and validation sessions.
Deliverables
Findings, priorities, target state, roadmap, risks.
End state
An informed decision about what to do next.
Ongoing support
Optional follow-on engagement.

Build

Primary purpose
Design and implement the GTM operating system.
Typical starting point
Architecture and priorities have been agreed.
Main activities
Architecture, configuration, data, automation, integrations, training.
Client involvement
Decision-making, review, testing, training participation.
Deliverables
Production system, documentation, training, dashboards.
End state
A working system the team can operate.
Ongoing support
Defined post-launch support period.

Embedded operation

Primary purpose
Run, maintain, and improve the system as the business changes.
Typical starting point
The system is live but lacks operating capacity.
Main activities
Administration, hygiene, releases, reporting, adoption, improvements.
Client involvement
Priority setting, business context, periodic reviews.
Deliverables
Ongoing releases, reporting, documentation updates, backlog.
End state
A maintained, evolving operating model.
Ongoing support
Continuous, scope adjusted over time.
HOW WE WORK FAQ

Practical questions about working with us.

Make the system visible before making it bigger.

Start with a practical conversation about the current process, data, tools, and operating constraints.

ԿապՊատվիրել հանդիպում