Before replacing the connector, examine the work your team does around it. Hidden maintenance is often the fastest route to the underlying RevOps problem.
Before replacing your HubSpot + Professional Services Automation (PSA) connector, observe your team's work for one week.
Observe the people, not the API logs or the sync status page.
Note what happens when sales needs a customer answer, when a deal moves to service, when a renewal changes, when a record looks wrong, or when leadership requests a forecast. Pay particular attention to the extra steps people take before they trust the system.
Those steps make up the Integration Maintenance Test.
Technical maintenance matters. Credentials expire, APIs change, and integrations fail, but many unhealthy environments do not appear broken at the technical level.
The sync is green while someone re-keys data. Records move while a manager checks both systems before approving a number. Workflows run while the team keeps a spreadsheet because the dashboard is "usually right."
People can compensate for weak architecture so effectively that the workaround starts to look like the process.
A RevOps assessment looks for the difference between intentional human judgment and manual work that exists because the system has never been given a clear rule.
Ask what people do before they use a customer, pipeline, renewal, or revenue number. Do they trust the record as it appears, or do they verify it somewhere else first?
Watch for duplicate records, mismatched statuses, inconsistent dates, fields with competing definitions, and values that are routinely corrected by hand.
Track the tasks that exist only because the integration does not fully support the process. That may include spreadsheet reconciliation, duplicate cleanup, re-entry, manual routing, handoff checks, or copying project and agreement details between systems.
The question is not whether manual work exists. Some work should remain human. The question is whether people are making business judgments or compensating for ambiguity.
Ask a few people which system owns important customer information. If the answers vary by person rather than by documented rule, ownership is not actually defined.
Pay special attention to fields that affect lifecycle stage, customer status, company classification, opportunity stage, agreement status, renewals, routing, or reporting.
Look at the reports teams use to manage the business. Which ones come with caveats? Which require manual cleanup? Which teams maintain their own version of the same metric?
Reporting is often where upstream issues become visible because it forces multiple systems and processes into one answer.
Identify the people who know the exceptions. Who gets the Slack message when two systems disagree? Who knows which field not to touch? Who remembers that one client needs a special workaround every month?
If the integration depends on those people being available, part of the architecture still lives in their heads.
|
A healthy integration should reduce manual work, improve confidence, and give your team time back. The goal is not zero human involvement. The goal is to reserve people for judgment, relationships, and exceptions that actually require them. |
The Maintenance Test is not an effort to eliminate every task a person touches, which would create the wrong incentive.
Some manual reviews are valuable controls. A complex exception may require a service manager. A sensitive account change may need approval. A financial adjustment may belong with a person, not a workflow.
RevOps helps separate those intentional controls from operational debt.
A useful question is: "How much of this manual work exists because the architecture has not made a decision?"
Repeated reconciliation points to ownership or mapping problems. Repeated handoff checks point to process or automation problems. Repeated report repair points to inconsistent definitions or incomplete data. Repeated exception handling may mean the "exception" is actually part of the normal process and should be designed into the architecture.
That changes the conversation from "Which connector should we buy?" to "What does the business need the systems to do differently?"
In some cases the answer is a different connector. In others it is new mapping logic, clearer system roles, better data governance, a redesigned handoff, or a report built on better definitions. The test supports diagnosing before replacing.
The first architecture diagram shows systems and arrows.
The second shows where people are still reconciling, checking, fixing, deciding, and remembering.
That second diagram is often the more useful one because it shows what the operating model actually looks like today. Once it is visible, the team can decide what to redesign.
|
VISUAL RECOMMENDATION | Figure 4.2 (specification only) (Jamie design graphic) Illustrate the second architecture diagram Type: Side-by-side before and after diagram Placement: After the paragraph that closes "The Second Architecture Diagram." Purpose: Make the concept concrete for readers who have only seen the systems-and-arrows view. Contents: Left panel: HubSpot and PSA with arrows. Right panel: the same systems with markers where people reconcile, check, fix, decide, and remember, each tagged with a role. Design notes: Use blue for intentional human controls and red for operational debt, reflecting the distinction the article draws. Alt text: Two architecture diagrams, one showing systems and arrows, the other showing where people perform manual work. |