A technical recommendation is stronger when the consultant pauses the question of which tool to buy. Start by finding out whether the operation can explain an occurrence from first report to closure, and what a new person would find when reviewing that case later.
Start with a real case, not the tool
Ask for a recent occurrence that represents normal work, not the most unusual incident. Follow where the event appeared, who owned the next action, which evidence was kept, how decisions were made, and what closing the case actually meant.
This path reveals more than an institutional presentation. It shows when context moves between channels, when ownership becomes implicit, and which part of the story exists only in a participant’s memory.
Interview the people who record, follow, and review
Do not limit the inquiry to one manager. Speak separately with the person who makes the first record, the person who follows the work, and the person who reviews the result. Compare their answers to simple questions:
- Where is the authoritative record?
- Who owns the next action?
- Where is the evidence?
- What does “closed” mean?
- How is an old case found?
Differences are diagnostic evidence. They may point to a missing rule, a record model that omits important information, or a tool that distributes the work across disconnected places.
Separate three kinds of problem
This distinction prevents a software recommendation for every symptom.
A process deficiency appears when nobody clearly owns follow-up, there is no update rule, or the team does not know when a case can close. A change in roles, routine, or closure criteria may solve it without changing tools.
An information-model deficiency appears when the record captures the event but not what is needed to follow it: evidence, participants, decisions, changes, or context. The next step may be redesigning a form or record structure before evaluating products.
A tool limitation appears when the process is clear and the team knows what must be preserved, but the current instrument cannot maintain the relationships and history at the required complexity. Examples include attachments kept outside the case, ownership changes left unrecorded, and a single row reducing a whole sequence to one status.
The three can coexist, but they are not interchangeable. Better software does not create discipline, and a better procedure cannot solve a structural limit that has already been demonstrated.
Signs it is not time to recommend a new system
Hold the recommendation when volume is low, one small team owns the work, a form or spreadsheet supports retrieval, and the main problem is uncertainty about who should update the record. Consider adoption capacity too: if the operation has not decided what information matters, a new platform may add fields without adding understanding.
The recommendation may be to clarify roles, reduce fields, improve a spreadsheet, adjust a form, or use the current tool better. The answer does not have to be a purchase.
Signs that a dedicated structure is worth evaluating
Evaluation becomes more reasonable when several teams or locations participate, ownership changes repeatedly, evidence is scattered, leaders or clients ask for recurring review, or closed cases are hard to reconstruct. Another sign is that the current instrument records that something happened but cannot show how the situation evolved.
These are still hypotheses, not conclusions. Confirm them across more than one case and compare the cost of a smaller intervention.
A diagnostic interview guide
Ask questions that make the team narrate the work instead of confirming a feature list:
- Walk me through the last occurrence from first report to closure.
- Where would I find each piece of evidence used in the decision?
- Who owned the case at each stage, and when did that change?
- What changes when another team or location becomes involved?
- Could a newcomer understand the case without interviewing the participants?
- Which parts of follow-up exist only in memory or conversation?
- What does the current tool fail to represent even though the process is clear?
Record answers and concrete examples. “Traceability is weak” is an impression; “the attachment is in an unreferenced folder and nobody knows which version supported the decision” is an observation that can guide a decision.
Test the hypothesis with more than one case
A single episode can distort the diagnosis. Compare a simple case, a case requiring extended follow-up, and, where relevant, one that crossed teams or locations. Look for a repeating pattern and for limits that appear only in exceptional situations.
If every case fails at the same point, the intervention should address it directly. If only a rare case requires a much larger structure, consider whether it is proportionate to create a permanent system for the exception.
How to present the recommendation
Structure the conversation in five parts: what was observed in the current state; what operational gap results; whether the main cause is process, information model, or tool; the smallest proportionate intervention; and which signals would justify reassessment.
A sound recommendation may be to improve the process, redesign a form, keep or better organize a spreadsheet, use an existing tool differently, or evaluate dedicated software. Explaining why alternatives were ruled out matters as much as naming an option.
When CGS is worth evaluating
CGS may enter the evaluation when the client scenario genuinely requires occurrences, responsible participants, evidence, interactions, and history to remain associated and consultable. A consultant can compare that possibility with smaller interventions and speak with Solinn about fit for a concrete case. This is a fit discussion, not a partner or referral program.
For purchase criteria, see what to evaluate before choosing a system and when dedicated software is actually needed.
