Solution Consultant: Mapping the Process Before Proposing the Product

A solution consultant works out how the customer's process should run with the product in it, and only then which configuration of the product supports that. The order matters. Starting from capability produces a proposal shaped by what the software happens to do well; starting from process produces one shaped by what the business needs to change, which is a much better predictor of whether anything improves after signature.

Where a sales engineer is also present, the division of labour is usually clean enough in practice: the engineer owns questions about the system, the consultant owns questions about the work. In smaller companies one person does both, and the risk then is that the easier question, the technical one, crowds out the harder one.

Current state

Draw what actually happens, as described by the people who do it, not as described by a policy document. Each step needs an owner, a trigger and an output. The interesting parts are the joins: where work waits for someone, where information is retyped, where two people do the same thing, and where something routinely gets lost. Buyers are often surprised by their own map, which is itself useful, because a shared picture of the present is the only stable foundation for a conversation about the future.

Future state

Draw the same process with the product in place. Mark clearly which steps disappear, which change owner and which stay manual. The manual steps are the credibility test. A future-state map with no manual steps left is a marketing diagram, and buyers who have been through an implementation before will recognise it as one.

The gap

The difference between the maps is the value case, and it should be built jointly rather than presented. A number the customer worked out with you is a number they will defend internally. A number you produced and handed over is one their finance team will take apart, and the time spent defending it comes out of the time you needed for everything else.

Use the customer's own inputs and choose conservative assumptions with them. Suppose a distributor tells you they send roughly 200 quotes a month, believe about a third are never followed up, and that the average order value is 45,000. Rather than claiming to recover every lost quote, ask them what a realistic recovery would be if follow-up were reliable. Whatever fraction they choose becomes the basis. The resulting figure is smaller than a vendor model would produce and immeasurably more durable.

Two further disciplines keep the case honest. State the costs alongside the benefits, including the internal effort of the change, because a case with no cost line reads as a sales document. And separate hard savings that appear in a budget from soft benefits like better visibility, which are real but should not be added to a financial total.

Every process change moves work and visibility between people. When head office gains direct sight of what dealers are ordering, a regional manager loses something they used to control. When approvals are automated, a checkpoint somebody valued disappears. These reactions are entirely rational and they decide implementations far more often than feature comparisons do.

Mapping who gains and who loses is therefore part of the job, not an optional refinement. It is uncomfortable, because the person who invited you is rarely the person who loses, and raising it means naming a conflict that your sponsor may have been avoiding. The alternative is a proposal that is technically sound, commercially agreed, and quietly resisted until it is abandoned.

Good consulting work produces a written summary that the customer recognises as an accurate description of their own business, including the parts that are unflattering. The value case uses their numbers. The future state names its manual steps. The stakeholder map has at least one person on it who is not enthusiastic. Implementation begins from that document rather than from a fresh discovery workshop.

Bad consulting work produces a polished deck built from industry assumptions, a future state designed around product capabilities, and a value figure large enough to require defending. It closes deals that then struggle in deployment, and the pattern is only visible a year later in the retention numbers, by which time it is attributed to implementation rather than to the sale.

A sales engineer answers the technical half of the same evaluation. A solutions architect designs the deployment after the sale. A business analyst does comparable process work from inside the customer organisation. An implementation consultant takes the agreed design and makes it real. The role most easily confused with this one is the sales engineer, and the practical distinction is whether the difficult questions in your deals are about the software or about how people will have to work.

Related pages on evaluations, process change and product fit:book a demo, use cases, features overview, what a CRM is, sales automation, and CRM by industry.