Frequently Asked Questions
Plain answers about how Dept.1 builds relationship systems for nonprofits, what working together looks like, and how to tell whether your team is ready.
Identifying the Relationship Systems and CRM Data Problem
A relationship system for a nonprofit is the combination of data, workflows, and ownership rules that keeps track of the people the organization depends on: donors and funders, partners and co-grantees, and program participants and clients. It usually includes a CRM or database, the processes that decide who enters what and when, and the reporting that comes out the other end. A working relationship system for donor, partner and program data gives any team member a current view of each relationship without asking the one person who remembers. Dept.1, a relationship systems and CRM consultant based in the Twin Cities, builds these systems for scaling nonprofits, and the client owns what gets built.
Data ends up in different systems because each team chose a tool when it needed one. Development bought a donor database, the program team built forms and spreadsheets, and whoever manages partners kept a tracker of their own. Each choice made sense at the time. Over several years the records stop matching, and one or two people become the translators between them. Replacing the tools rarely fixes this on its own, because the new tool inherits the same unanswered questions: which system holds the official record of a relationship, who updates it, and how it connects to the other two. The fix starts with defining those rules across all three kinds of relationships, then configuring the platforms to match. A Relationship Architecture Review does that design work before any build begins.
A nonprofit's relationships have outgrown its systems when the people responsible for managing those relationships can't see a complete picture without searching three different tools or calling a colleague. The practical markers: renewal dates slip because tracking lives in one person's inbox, funder reports take several staff days to assemble by hand, and no single record shows how a donor, partner, or program participant connects to the organization over time. The system was workable at a smaller scale. At the current scale, it creates real risk for funding, for relationships, and for the organization when a key person leaves. This is the condition a Relationship Architecture Review is designed to diagnose.
The clearest signs are operational friction with funding consequences. Staff spend significant time assembling reports manually before each funder deadline. Ask cycles and renewals slip because the schedule depends on one person's calendar or inbox. The same relationship appears differently in two different tools. Program data can't connect to funder reporting without a manual data pull. A staff transition creates an immediate data crisis. Any of these in isolation is a workflow problem. Several together, or any one combined with a board ask or a funder reporting demand, indicate that the structure underneath the workflows needs attention, not just a new tool.
The cost takes three forms: wasted spend on platforms that don't integrate or aren't fully used; staff time absorbed by manual data work that a structured system would make routine; and funding at risk when reporting is slow, incomplete, or dependent on staff who may leave. For organizations managing federal or multi-funder grants, the third category is growing. Roughly a third of nonprofits experienced federal funding disruption in 2025 (Urban Institute). Late or thin reporting now puts renewals at risk, not just hours. The specific figures vary by organization. Run against your own numbers, the annual cost of leaving it alone tends to dwarf the cost of fixing it once those three categories are counted.
The database stays, but the knowledge of how to use it leaves with the person. Typical losses include which fields can be trusted, which spreadsheet holds the real renewal dates, how a funder report gets assembled, and which records were corrected by hand and never updated in the system. The successor spends weeks reconstructing what the previous person did from memory, and asks and renewals can slip in the meantime. Organizations with a documented donor and relationship system handle the transition differently, because an incoming person can learn the process from written procedures. The same risk applies to partner and program data when one person holds that picture. Writing the process down and naming an internal owner reduces the risk before anyone gives notice.
A CRM problem is a technology problem: the platform doesn't do something the team needs, records aren't being entered consistently, or two tools can't share data. Configuring the platform differently, or replacing it, solves a CRM problem. A relationship systems problem sits underneath the platform. The team has no clear definition of how a donor, partner, or participant relationship moves from first contact to active management to reporting, whatever tool does the tracking. Changing the platform leaves that definition missing, so the same breakdowns reappear in the new tool. A Relationship Architecture Review diagnoses which problem is present before any tool decision is made.
Donor and Funder Relationship Systems and CRM Data
Data quality problems in a nonprofit donor database usually come from three gaps. The first is a missing definition of 'active.' When one person counts anyone who gave in the last 12 months and another counts the last 24, the same list returns two different totals. The second is duplicate records, which split a donor's giving across several entries. The third is gifts and contact updates that live in another tool or spreadsheet and never reach the main record. The fixes are a written definition for each donor status, a merge rule with a named owner, and an agreed path for getting every gift and update into one place. A new platform supplies none of these, so the list stays unreliable until they exist. The Relationship Architecture Review maps where the donor record breaks and defines these rules before any cleanup begins.
When funder data is spread across a CRM, a spreadsheet, and a development director's calendar, the renewal schedule depends on the one person who synthesized it. That is a structural problem, not a workflow one. The fix is a donor and funder relationship system, built on a CRM or similar platform, that maintains a single, complete record for each funder relationship, with defined ownership and review logic built in, so the schedule doesn't depend on any one person's memory or attention. Defining what that record should contain, who reviews it and when, and how it surfaces upcoming deadlines is the design work a Relationship Architecture Review produces before any tool decision is made.r placeholder. Replace this text.
The work needs someone who can handle both the data and the process behind it. A database administrator can clean records and connect tools, but the fix holds only if someone also decides which system is the official record for each type of data, who updates it, and how the pieces reconcile. Look for a nonprofit CRM consultant who starts with that design question and works across the platforms you already use. Dept.1 is a relationship systems and CRM consultant based in the Twin Cities. It does this work for donor and funder data, and for partner and program data when those live in separate places too. The client owns the documented result and can run it without Dept.1, a software vendor, or any one staff member.
Start with what is failing. If the platform lacks a capability the team needs and cannot be configured to add it, migration is worth considering. If the capability exists but isn't set up, connected, or used consistently, migration moves the same problems into a new system and adds the cost of moving the data. Teams often reach for a new CRM when the underlying cause is undefined process: no agreed donor stages, no field ownership, no standard for when records get updated. A defensible answer comes from a list of what the team needs the system to do, tested against the current platform. The Relationship Architecture Review produces that list and a recommendation to invest further in the current system or evaluate alternatives, before any build or migration spending is committed.
By designing the reporting process before the grant cycle starts. A funder reporting system should connect program data to grant records without a manual pull each cycle, show anyone on the development team the status of every active grant (what was promised, what has been delivered, and when the next deadline falls), and produce a first-draft report from data already in the system. It should also hold each funder's reporting history somewhere that survives staff transitions. Rebuilding reports by hand usually traces to two causes: program data isn't captured in the format the funder asks for, and the grant record carries no clear timeline of what is due. Both are process and configuration problems. Adding staff to an undefined process produces more data without clarifying it. The more durable fix is a defined workflow: what gets entered, by whom, on what schedule, and how it connects to the funder record at reporting time. Most nonprofits already own tools capable of this, and the gap is usually in how those tools are configured and connected. Nonprofit funder reporting automation works once that workflow exists.
Carefully, and in a defined sequence. The most common mistake is treating migration as a data problem (exporting the spreadsheet and importing it into a new tool) without first deciding how funder tracking should work in the new system. Data that goes in without a clear structure comes out the same way. The better sequence is to define the future-state process first (what the funder record should contain, who maintains it, and how it connects to reporting), then design the migration to match that structure, so what's preserved is the relationship knowledge, not just the fields. A Relationship Architecture Review produces that structure before any migration begins.
Build it with the team that will run it, and document it as it is built. A donor system a team can own has four parts: a data structure sized to how the team works (the fields, stages, and rules they actually need), written procedures for routine tasks such as entering gifts, merging duplicates, and producing standard reports, a named internal owner who understands the configuration, and training for the people who use it daily. Systems that depend on a consultant usually lack the written procedures or the internal owner. At the end of each Dept.1 build phase, the documentation and the internal-owner handoff are part of the deliverable, so the donor database doesn't depend on Dept.1, a software vendor, or the one staff member who built the original spreadsheets.
Partner and Co-Grantee Relationship Systems and Data
The organizations managing this well don't try to centralize every record. They define a minimal shared data standard: what each co-grantee reports, in what format, on what schedule, and where it goes when it arrives. That standard becomes the backbone of the accountability system. Without it, the lead organization spends the weeks before each funder deadline assembling reports from inconsistent formats and chasing partners for missing pieces. With it, consolidation is a defined process rather than a reconstruction effort. Building that standard is a design decision, not a technology one, and it's one of the things a Relationship Architecture Review produces for partner and co-grantee tracks.
Give every partner one record that the whole team reads and updates, and retire the side spreadsheets once that record holds what they hold. For a network of ten or more organizations, a partner record should carry the relationship history, current obligations, key contacts, and reporting cadence, in a place the program or grants team can use without a data specialist. It should distinguish partner types, because a co-grantee has different accountability obligations than a referral partner or a service provider, and it should show who hasn't reported or responded without a separate checklist. Moving off spreadsheets starts with agreeing on those fields and who maintains them. The platform varies with the organization's existing stack. The structure of the record is the same in a CRM, Airtable, or Monday.com.
Look for a consultant who has built tracking for relationships between organizations, not only for individuals, and who starts with how the partnership works before choosing a platform. Partnership tracking covers shared history, who owns each relationship, what each side has committed to, referral flow in both directions, and the reporting a funder or state agency requires. Useful questions for any candidate: how they define a partner record, how they handle partners that report in different formats, and what the team can maintain after the engagement ends. Dept.1 builds these systems for scaling nonprofits across partners and co-grantees, alongside donor and funder data and program participant data, and the client owns and can run what gets built.
The manual assembly problem is almost always a data-standards problem. Each partner reports in a format that made sense to them, and the lead organization reconstructs a coherent picture from the pieces. The fix is a defined reporting template and submission process that each partner uses, so what arrives is already in the format the lead organization needs. Building that standard is a design decision, not a technology decision, and it holds whether partners are submitting into a shared platform or emailing a spreadsheet. A Relationship Architecture Review identifies where the current standard breaks and what the replacement should look like.
A grants management system tracks the financial and compliance obligations of a grant: disbursements, budget lines, required reports, and deadlines. A partner relationship system tracks the relationship itself: the history of engagement, the contacts, the program delivery obligations, and the accountability checkpoints over time. Many organizations need both, and confusion between them is common. Organizations often adopt a grants management tool expecting it to handle relationship tracking, or vice versa, and find that neither works quite right for the other purpose. Clarifying which problem is actually present is part of what a Relationship Architecture Review determines.
Program Participant and Client Relationship Systems and Data
Activity numbers count what the program did: sessions held, people served, hours delivered. Outcomes describe what changed for participants, such as a job placement, a housing move, or a skill gained. Reporting outcomes requires capturing them at the participant level over time, with a baseline and a follow-up, and tying each one to the same participant record that holds the service history. Programs that log only activity can't produce outcomes later, because the data was never collected. The work is defining, with each funder's outcome measures in hand, which fields to capture, when, and by whom, so the outcome enters the record as a normal part of service delivery. The Relationship Architecture Review for a program participant track maps this against the measures funders require.
Put the entry point where the service happens: a form or screen the staff member completes during or right after the session, on a device they already use, with only the fields the program and its funders use. Rebuilding from paper later happens when entry feels like a separate task, in a format that doesn't match how staff think about their caseload. Short, structured fields for attendance, milestones, referrals, and contacts capture what staff already track, and the same fields feed funder reporting without re-entry or reformatting. Getting there requires a map of what each funder needs and how the program workflow currently produces it. That map is part of what a Relationship Architecture Review delivers before any system is built.
Monthly reports get rebuilt by hand when the underlying data lives in documents instead of fields: scanned forms, PDFs, and emailed spreadsheets that someone retypes before each deadline. The fix is to move the data into structured fields once, at intake or at the point of service, and to define the monthly report as a view of those fields. The report then refreshes from the same records the program team already maintains. For one client, monthly partner and impact reporting that took about a day per program by hand now refreshes in one click. Getting there starts with listing every number in the current report and tracing where each one comes from. The numbers with no structured source are where the redesign begins.
Look for a consultant who designs the intake process and the outcome measures together, because both depend on the same participant record. Intake decides what is captured at the start, outcome tracking decides what is captured over time and at exit, and funder reporting depends on the two lining up. Useful questions for any candidate: how they define the participant record across programs, how they decide which fields staff will complete, and what documentation the team receives. Dept.1, a relationship systems and CRM consultant in the Twin Cities, builds intake and outcome tracking for program participants and clients, along with donor, funder, partner, and co-grantee data. The client owns the documented system.
At minimum, a participant-tracking system should hold a complete record for each participant across every program they've touched, so the organization can see the full relationship over time rather than a series of disconnected service events. It should capture the outcome data funders need in the same workflow program staff use to deliver services, not in a separate data-entry step. It should let a program director see, at any point in the grant cycle, how current enrollment and outcomes track against what was promised. And it should survive staff transitions. The participant record and service history should exist independently of the person who entered them.
Participant records that live in program-specific silos don't follow the person across programs. A participant who moves from one program to another starts over as a new record, losing the history of the prior relationship. The organizations managing this well maintain a single participant record that spans programs, with program-specific service data linked to that record rather than replacing it. Building that structure requires deciding where the participant record lives, what it contains, and how each program's data attaches to it. Those decisions are harder to make after each program has already built its own tracking system.
The Relationship Architecture Review
A Relationship Architecture Review is a roughly three-month assessment of one nonprofit relationship track: donors and funders, partners and co-grantees, or program participants and clients. It includes five structured discovery sessions with the team members who touch the track day to day, a root-cause analysis of why the current breakdowns keep happening, a future-state workshop to define how the relationships should be structured, a quantified accounting of what the current state is costing, and a sequenced roadmap with fixed-bid pricing for each build phase. The organization keeps everything the Review produces (the workflow map, the cost accounting, and the roadmap), and the plan is built to stand on its own whether the next phase is built with Dept.1 or not.
The Review fits growing nonprofits, generally $3M to $50M in annual budget, whose relationships have outgrown the tools and processes tracking them. Dept.1 is a relationship systems and CRM consultant based in the Twin Cities, and the Review is the starting point for its donor, partner, and program data work. The common condition is a team of three or four people responsible for the large majority of the organization's relationships, with records spread across systems that don't reconcile and the full picture held in one or two people's memory. Organizations typically start a Review when a board ask, a funder reporting demand, a platform decision, or a staff transition makes the gaps urgent enough to address directly.
A free assessment is typically a sales step toward one platform. The Review is system-agnostic and produces two things a vendor cannot: a quantified accounting of what the current state is costing the organization, drawn from structured discovery conversations rather than a feature checklist, and a roadmap the organization owns regardless of what it builds or with whom. The design of the future-state system is resolved before any platform question, which means the recommendation is grounded in the team's actual requirements, not a product's capabilities.
Not necessarily. The Review produces a defensible recommendation on whether to invest further in the current platform or evaluate alternatives, based on a defined set of functional requirements the team develops through the process. Some organizations configure and extend what they already have. Others move to a different platform. The Review determines which path makes sense before any build spending is committed, which is what makes it a different kind of decision than a vendor evaluation.
The Review can be accomplished in as little as 4-5 weeks and is a fixed-bid project priced based on the needs of your organization, generally around $15,000. Pricing is scoped to the size and complexity of the relationship track under review.
The Review produces a sequenced roadmap with fixed-bid pricing for each build phase. From there, organizations can move into implementation, building the systems the roadmap calls for, in phases they can approve independently. Nothing commits the organization to the full roadmap upfront, and the plan is documented to stand on its own if the organization takes the next phase to a different vendor or builds internally.
Implementation and Ownership
Implementation builds the relationship system for donor, partner and program data that a Relationship Architecture Review or a First Stop define: the data model, the workflows, and the processes for managing the relationship track across the full lifecycle. The deliverable is a configured, documented system the team can run without outside support. Documentation covers how the system is structured, how each process works, and what to do when something breaks. It's written for this team, with this data, in this workflow. Not a generic user guide for a standard setup.
Yes. Implementation is broken into discrete phases, each scoped and priced independently. An organization can approve one phase, complete it, evaluate the result, and decide whether to continue, without committing to the full roadmap upfront. The sequencing comes from the Review: phases are ordered by value and operational need, so the first phase addresses the highest-cost gap or the most urgent reporting requirement.
At the end of each pahse, Dept.1 hands off documentation and works with the organization to identify and enable an internal owner: someone on the team who understands how the system works and can maintain it going forward. The documentation covers the structure of the system, the workflows it supports, and the process for common maintenance tasks. The goal is that the internal owner can run the system, train new staff on it, and troubleshoot routine issues without calling in outside help.
The documentation is the protection. An organization with a documented system and a defined process can train a new owner from what's written down, the same way it would onboard someone onto any other organizational process. The system doesn't depend on any individual, Dept.1's or the client's, to keep running. Whether an incoming person can understand the system from the documentation is the practical test for whether the ownership promise is real.
Not for routine operation. The system is designed to run without ongoing consultant involvement. Some organizations engage Dept.1 for periodic advisory when they are extending the system to a new relationship track, evaluating a platform change, or onboarding a new internal owner, but that's a discretionary choice, not a dependency. The system and its documentation belong to the organization and are built to stay functional regardless of whether the engagement continues.
Measuring Success
The most direct measures are operational: renewal rates stay on schedule without manual reminders, funder reports get produced in hours rather than days, program staff spend less time on data entry, and a staff transition doesn't put institutional knowledge at risk. A well-designed relationship system on top of the CRM makes these outcomes visible. The team can see, at any point, how each active relationship is moving and what's pending. The absence of that visibility is itself a measure of where the current system falls short.
The most direct results are time recovered and risk reduced. A well-built relationship system for donor, partner and program data is designed to produce a consistent pattern: reporting that required days of manual assembly refreshes automatically or near-automatically, development staff spend more time on relationships and less on data management, and the team can respond to a board ask or a funder request without a week of preparation. For one client, monthly partner and impact reporting that ran about a day per program by hand now refreshes in one click. The specific gains depend on where the current system is most broken and what gets built to address it.
The value-driver table produced in the Relationship Architecture Review or a First Stop report is the baseline. It quantifies the current state across three categories: spend already on the books that is wasted or recoverable, staff time lost to manual work, and revenue or funding at risk. After implementation, those same categories are the measurement frame: did the recoverable spend get recovered, did the time loss decrease, did the at-risk funding renew? The organizations that measure this most clearly are the ones that build the cost-of-inaction accounting into the decision to engage, so the baseline exists before the work starts.
The Review or a First Stop produce a deliverable the organization can act on from the day it's delivered. The cost of inaction accounting and the roadmap are immediately useable. Implementation phases are sequenced to start from high-value, lower-complexity work, so early phases tend to produce visible changes faster than later ones. Operational changes (reporting time, renewal visibility, staff time saved) usually become measureable within one to two quarters after a phase is complete.
Yes, in part because the Review or the First Stop builds the measurement baseline through the discovery process. The value-discovery questions in each session gather the specific figures the organization is starting from: how long a given process takes, how often it breaks, what it has cost. Those numbers become the before-state against which the after-state is measured. Organizations that feel they lack good baseline data often find the discovery process surfaces more than they expected. The data exists, it's just not assembled anywhere.
Working with Dept.1
Dept.1 Solutions is a relationship systems and CRM consultant based in the Twin Cities. It builds systems that hold a nonprofit's donor and funder, partner and co-grantee, and program participant and client data, for scaling nonprofits with annual budgets of $3M to $50M. Each system is documented and fitted to how the team already works, and the client owns it without depending on Dept.1, a software vendor, or one staff member. The work starts with a Relationship Architecture Review, which defines how the relationships should be structured before any platform decision is made.
A relationship systems consultant for scaling nonprofits assesses how donor, funder, partner, and participant information moves through the organization today, designs how it should move, builds the systems to match, and hands them to the team to run. At Dept.1 that starts with a Relationship Architecture Review (assessment and a sequenced roadmap with fixed-bid pricing), continues with implementation in phases the organization approves independently, and finishes with documentation, internal-owner enablement, and advisory support when the organization wants it. The consultant covers all three kinds of relationships, donors and funders, partners and co-grantees, and program participants and clients, because a scaling nonprofit manages all three at once. The work fits a nonprofit whose relationships have outgrown its tools and whose records live across systems that don't reconcile.
Dept.1 is based in the Twin Cities and works primarily with nonprofits in the $3M to $50M annual budget range whose relationships have outgrown the systems tracking them. The common profile is an organization with a team of three to five people managing the large majority of its donor, funder, partner, or program relationships, facing a reporting demand, a platform decision, a board ask, or a staff transition that makes the current gaps urgent. The sectors that come up most often are human services, workforce development, and youth-serving organizations, though the qualifying condition (more relationships than the current tools and team can hold) is the real filter.
A Relationship Architecture Review is fixed-bid, scoped to the size and complexity of the relationship track under review, generally around $15,000. The organization knows the full cost before any work begins, and a payment plan is available.
The Review itself runs approximately 4-5 weeks at the fastest. Implementation phases are scoped and sequenced after the Review, so the total timeline depends on how many phases the organization chooses to undertake and in what order. A single-track implementation typically runs three to six months after the Review concludes, with the option to pause between phases. Organizations that move through a Review and a first implementation phase consecutively are generally looking at six to nine months from start to a functional, documented system.
The Review and the First Stop requires access to the team members who touch the relationship track day to day, typically three to five people for the discovery sessions, and a point of contact on the client side who can make scheduling and content decisions. Sessions are 60 minutes each. With preparation provided for each one. Implementation requires the same point of contact and a named internal owner who will take over the system at handoff. The engagement is designed to fit into a working week, not to require a major time commitment on top of existing responsibilities.
The starting point is a conversation to determine whether Dept.1 can provide the right help. Visit this scheduling page to schedule a time.
Technology and Tools
A nonprofit CRM consultant helps an organization choose, configure, connect, and use the platform that holds its constituent data, such as Salesforce NPSP, HubSpot, or Bloomerang. The work usually includes defining what the CRM should track, setting up fields, workflows, and reports, connecting it to other tools like email, payment, and case-management systems, migrating data, and training staff. You need one when the CRM is underused or distrusted, when two systems hold conflicting records, when funder reporting requires a manual rebuild, when a platform decision is coming, or when the one person who understands the configuration is leaving. Dept.1 does this work as part of a wider design of donor, partner, and program relationships, so the CRM serves a defined structure.
When data that belongs together lives in separate tools and moves between them by export, copy and paste, or one person's memory. Typical triggers include donation or event platform data reaching the CRM late or with duplicates, program data sitting in a forms or case-management tool that funder reporting can't see, an email platform out of sync with the donor database, or a new tool added without a plan for how its data connects. An integration consultant maps which system is the source of truth for each type of data, designs how records match and sync, and builds and documents the connections. Integrations only help once the data rules behind them are settled, so Dept.1 defines those rules first and then builds the connections, documented so the team can maintain them.
Peers and directories are the usual starting points. Development directors and executive directors at similar nonprofits can say who they worked with and what changed. Local directories, including the AFP Minnesota consultant directory and the Minnesota Council of Nonprofits listings, collect consultants who serve the sector. Though not all consultants may be listed as those placements tend to require fees. Compare candidates on fit: whether they work across the platforms you use or sell one, whether they price work as fixed-bid or hourly, whether they document what they build, and whether your team can run the result without them. Ask each one to describe a comparable engagement at the level of the problem solved. The next question covers what else to ask before hiring.
Ask whether the consultant is tied to a platform or vendor, and how they decide what to recommend. Ask what the deliverables are and who owns them, including documentation. Ask how the work is priced, and whether the full cost is fixed before work begins. Ask what the engagement requires from your team and how much time that takes. Ask what happens if your internal owner leaves, and whether someone else could run the system from the documentation. Ask for a description of a comparable engagement, at the level of the problem and the result, with the client named only if they have agreed. The answers show whether the consultant is building a system your organization owns or one that depends on the consultant.
Vendor lock-in means an organization can't leave a platform, a consultant, or a configuration without losing data, rebuilding the system, or paying heavily to move. For a nonprofit CRM it shows up in three places: the data (whether complete records can be exported in a usable format), the configuration (whether it is documented well enough that another person or firm could change it), and the relationship with the implementer (whether the team can run the system without the consultant). No lock-in means all three are covered. Dept.1's standard for donor, partner, and program data is that the client owns what is built: it is documented, fitted to how the team already works, and does not depend on Dept.1, a software vendor, or one staff member.
Dept.1 works across the range of platforms nonprofits commonly use, including Salesforce NPSP, HubSpot, Bloomerang, Monday.com, Airtable, and others, depending on what the client already has or what the Relationship Architecture Review recommends. The firm is not affiliated with any vendor and does not have a preferred platform to sell. Platform recommendations come from the functional requirements the team develops through the Review, not from a prior relationship with a software company.
No. The Relationship Architecture Review and the First Stop are system-agnostic. They produce a recommendation on whether to invest further in the current platform or evaluate alternatives based on the team's actual requirements. Some organizations that go through the Review or the First Stop keep the platform they already have and configure it differently. Others migrate to a different system. The Review and the First Stop are designed to answer that question before any platform spend is committed.
A CRM implementation vendor's scope begins and ends with a specific platform: they configure it, migrate data into it, and train the team to use it. Their expertise is the tool. A systems consultant's scope begins with the structural problem (how the relationships should be managed) and works backward to the platform that best serves that structure. The work includes designing the relationship architecture before any tool decision is made, which is what prevents the common pattern of implementing a new CRM that produces the same problems as the old one.
Usually yes. Most implementations build on platforms the organization already has access to or is already paying for, rather than requiring new software purchases. The question the Review resolves is whether the current tools, configured and connected correctly, can support the relationship architecture the team needs, or whether the functional requirements call for a different platform. That determination is based on what the team actually needs to do, not on what any vendor recommends.
Data migration is a design decision before it is a technical one. The most common migration failure is treating it as a data-transfer problem (exporting the old records and importing them into the new system) without first deciding how the new system should be structured and which data is worth bringing over. Records that go in without a defined structure come out the same way. The approach is to design the future-state data model first, then plan the migration to match it, so what's preserved is the relationship knowledge in a usable form, not just the volume of records.
Still have a question?
Ask us directly. We will answer in plain language, and tell you honestly if we are not the right fit.