Begin with the decision you need to make
Frame the question in operating terms. For example: why do customer requests need repeated follow-up before anyone can confirm the next step? Which information is missing, who has authority to act, and what must remain dependable while the process changes?
Define the starting and finishing points, the teams and systems involved, and important exclusions. A review of one handoff is different from an assessment of an entire business. The scope should make that distinction understandable to the people participating.
You do not need a finished technology specification to begin. You do need a question whose answer could change a decision.
Look for usable answers, not document volume
The output might be a compact brief with linked evidence, an annotated workflow and a prioritized action list. The format matters less than whether another responsible person can follow the reasoning.
| What the work should make clear | How to judge its usefulness |
|---|---|
| The operation as it works today | Can staff follow the ordinary path and important exceptions, including handoffs, records and owners? |
| Findings and their basis | Can you distinguish an observation from a reported explanation, an assumption and an unanswered question? |
| Improvement priorities | Is each priority tied to a consequence, supporting evidence, dependencies and someone responsible for the next step? |
| Practical alternatives | Can you see why retaining, repairing, connecting or replacing something deserves consideration? |
| The next decision | Is it clear what can be decided now, what needs further evidence, and what a proposed test would need to demonstrate? |
A long list of software features is not a substitute for this connection. Neither is a polished diagram that omits the exception everyone handles in email.
A small example of an assessment output
Illustrative example. Imagine an office receives a customer request, records a note and says a dispatcher will follow up. The business wants to understand why staff cannot consistently identify the next action.
Question. How should an incoming request remain visible until an authorized person confirms an appointment or explains the alternative?
Evidence to examine. Representative request records, the intake and dispatch steps, current configuration, staff explanations and the records used to confirm appointments.
Possible finding. A request note records the conversation but does not identify a follow-up owner or a distinct unconfirmed state. That finding would need checking against actual records and practice.
Uncertainty. The review has not established available scheduling capacity or whether the existing application can support the required state. It cannot promise an arrival time or a particular integration.
Alternatives. Clarify ownership and the staff checklist; test a supported request status in the current application; or investigate a connection if the required handoff is not supported. Replacement has not been justified merely by finding an unclear handoff.
Proposed next check. Follow an approved test request through intake and dispatch. Confirm that an unconfirmed request remains visible with an owner, a real booking has confirmation, and repeated input does not create unintended duplicate work. Record what happened and what remains unresolved.
The existing sample decision brief shows a fuller format using a different operating question: invoice readiness.
Know what the assessment does not automatically include
An assessment is not an implementation contract, a comprehensive security audit, certification or a guarantee of savings. A proposed connection still needs appropriate access, compatibility checks and testing.
Implementation, ongoing support and any access to live systems should remain separately agreed. Timing and fees follow the scope, evidence access, participation and commercial terms—not a promise made before the work is defined.
Bring enough context to define the work
Start with one recent example, the people who perform and own the work, the systems involved, and the decision you face. Include a known exception if it changes the question. Explain which records are sensitive and who can authorize their use.
Use a non-confidential outline for the first conversation. Do not send account passwords or unapproved detailed customer records simply to describe the problem.
Before proceeding, agree scope, exclusions, deliverables, access, responsibilities, timing and fees. Ask how findings will be reviewed with the people doing the work and who will own unresolved questions after the assessment.
Leave with a clearer next step
A useful assessment may support a correction, a test, further investigation or no immediate technology change. The point is to know why that next step is justified and what should remain unchanged.
Explore a business technology assessment
Review the approach, expected work products and fictional brief before deciding whether an assessment fits your operating question.