A completed implementation does not establish demand for a second project. Start by documenting the delivered scope, identifying operating dependencies outside that scope and checking changes since project discovery.
Why project documentation is insufficient for account planning
For a CRM partner or software development firm, completed delivery creates a durable relationship but not necessarily a new buying situation. The delivery team understands the requirements it was asked to implement. Its account manager may understand the customer's stakeholders and budget history. Neither view guarantees a current model of how the customer's whole business earns and delivers.
That gap is not automatically a failing of account management. The original project may have been sponsored by one department, funded against a particular problem and signed off at an agreed scope. Operations, Service and Finance can continue working with different data and constraints. The most important issue after go-live could sit entirely outside the commissioned solution.
Step 1. Record the delivered system boundary
Record the delivered entities, workflows, integrations and reports. Then annotate what these support: sales forecasting, enquiry handling, contractual renewal, inventory control or another decision. Do not assume that all related processes belong in the same system. Describe the domain at business level before assigning a platform.
| What you know | What it does not establish | Question worth asking |
|---|---|---|
| Deals and revenue are reported | Whether the business sees the cost and capacity of delivering those deals | How do commitments made in sales change delivery plans? |
| Customer accounts are maintained | Whether assets, locations or contracts have their own lifecycles | What is the unit that service teams actually manage? |
| Workflows automate stage transitions | Whether stage ownership, exceptions and escalation rights are agreed | What happens when the standard workflow does not fit a case? |
| Management dashboards are available | Whether leaders can act before the outcome is already determined | Which decision is still made without sufficient information? |
Step 2. Research the client and label uncertainty
Corporate websites, service menus, locations, product lines, recruitment patterns and public announcements can establish parts of a business model and suggest where complexity might exist. They rarely show how job costing works, how capacity is allocated, or which systems already support the process. Separate observations, plausible interpretations and unanswered questions in the research output.
For example, a business advertises a new service location. That is an observable change. It could imply more scheduling complexity; it might also be a small team working in the existing system. A well-framed follow-up is: "How are jobs allocated and equipment histories shared across the two locations now?" Not: "You need a new field-service platform."
Step 3. Select questions that could change an IT decision
A worthwhile account-development question must satisfy three tests. It must relate to a consequential part of the client's operating model; the answer must plausibly affect whether further technical work is needed; and the supplier must be able to have the conversation without pretending to know the client's internal situation.
If a question fails the first test, it is trivia. If it fails the second, it is useful account knowledge but not research for an IT intervention. If it fails the third, the provider risks using speculation as a sales tactic.
Step 4. Assign validation to the account owner
Research can recommend a conversation and specify what evidence would confirm or reject a candidate. The client's team must confirm operational problems, constraints, priorities and decision rights. Solution architects then choose whether the answer is a system extension, integration, change in process or no technical change. The account manager owns the commercial relationship throughout.
Acceptance test for the report: the account owner can state the relevant business decision, identify a previously unexamined question and specify which answer would reject the proposed intervention.
Continue with the distinction between an Intervention Candidate and a qualified opportunity. For a structured single-client review, see the Account Intervention Assessment.
Methodological analysis for CRM and software delivery partners. Scenarios are hypothetical and do not imply experience with a named customer.
Related method: Sales-to-service handover and operating rules
About these notes. ProperBizFix uses business-model and system-coverage analysis to identify questions worth testing with an existing client. Examples are illustrative unless expressly described otherwise. How the research works.
What should the account team do differently after the review?
A useful output changes the next conversation. Compare two possible statements:
| Weak account-plan item | Research-based validation |
|---|---|
| Propose asset management features. | The client maintains an installed equipment base. The CRM scope shows accounts and deals, but does not establish where assets, service visits and warranty events are managed. Ask who maintains those records and which decision they support. |
| Sell another dashboard. | The client sells contracts requiring scheduled labour. Establish whether work orders and labour estimates are recorded at job level, and whether a manager makes staffing decisions using that information. |
| Cross-sell automation. | A new site was announced. Establish what workflows have changed across locations before identifying a suitable integration or automation scope. |
Classify the result before putting it into the sales pipeline
Use four distinct outcomes: investigate now (a materially relevant question and enough evidence for the conversation); monitor (a plausible future change, but not yet actionable); stop (current evidence argues against further work); and unknown (the available sources cannot support even a preliminary judgement).
An account owner may then validate a candidate with the end client. Only after the need, buyer, scope and next decision are established does it become a sales opportunity. Counting unverified candidates as pipeline would overstate expected revenue.
Why this differs from a quarterly business review
A quarterly business review may cover system performance, adoption, support and objectives. This research begins with the business's operating dependencies and asks whether the delivered solution supports the relevant decisions. Both activities can coexist: an account review is not a substitute for understanding whether the original project delivered value.
Limits: external sources can establish public changes and possible operating dependencies, not hidden process failures, budget or actual profitability. Record those as questions; do not invent defects. Where the client already has adequate controls, recommend no technical change.
Further reading
The Consultancy Growth Network describes the commercial need to distinguish account development from reactive client delivery. Its recommendations concern account management; the worksheet above provides a separate evidence structure for deciding what requires further technical investigation. Consultancy Growth Network: growing existing accounts.