How specialist selection works
Turn an operating problem into a clear assignment before choosing a provider, a specialist, or a tool.
A practical process guide · 4 min read
Why this step matters
A request such as "we need an AI expert" describes a possible resource, not the operating problem. The real need may be missed bookings, unreliable maintenance records, slow financial reporting, or a team that cannot support a new system. Different problems require different experience. Buying a familiar name before understanding the work can create an expensive mismatch.
Start with the people who perform the work, the person who owns its result, and the records that show where it breaks down. Separate a shortage of time from a shortage of capability. Sometimes the answer is training, a simpler workflow, or a small discovery assignment rather than a larger external team.
Professional context: CIPS starts its procurement cycle with the business need and specification. Our practical approach below turns that principle into a project brief.
What we work through
State who needs a better result and what should change for them. "A dispatcher can see every unassigned job and its next action" is more useful than "install a dashboard." Include why the issue matters, how often it occurs, and the consequence of doing nothing.
Review the current workflow, systems, samples, exceptions, and handoffs. Record the source and period of any baseline measure. If nobody has measured the problem, mark that as an information gap and agree how to investigate it rather than inventing a savings estimate.
List the sites, users, interfaces, deliverables, and exclusions. Identify data sensitivity, access restrictions, operating hours, budget limits, and dependencies. A reporting pilot is not automatically permission to replace a booking platform or change a machine controller.
Translate the work into relevant experience: process analysis, API integration, instrumentation, data validation, training, or interim leadership. Distinguish essential competence from useful familiarity with a particular product. Name any required field qualification or independent review.
A deliverable is what is produced; an acceptance condition is how it will be checked. A workflow map might need confirmation from the people doing the work. A data feed might need reconciliation against source records and a visible failure state. A handover might need an operator to complete a routine task without the specialist present. Agree the evidence and the person authorized to accept it.
Write assumptions separately from requirements. If access, data quality, or technical feasibility is uncertain, use a bounded discovery stage with a decision at its end. This prevents an exploratory question from quietly becoming an open-ended build.
What this step produces
The brief should be short enough to use in a real discussion. For a small advisory assignment it may be a few clear pages. A safety-sensitive implementation needs more explicit technical and operational controls. Document detail should follow consequence, not ceremony.
Scenario, not a client result
The initial request: "Find someone to automate our appointments." A short review instead finds that unanswered calls, unclear service durations, and exceptions requiring owner approval are mixed together. Automating the current process without separating these issues could make the confusion faster.
The better brief: map the intake and booking rules, identify which requests can be handled safely, and prototype a request-to-review workflow using test data. Keep the existing calendar authoritative. Exclude payment changes and automatic confirmation of unusual bookings.
The acceptance discussion: test ordinary requests, unavailable staff, duplicate submissions, cancellations, and missing information. The operating manager reviews the results and the proposed exception queue before any live booking permission is considered. No percentage improvement is promised without a measured baseline.
The sourcing implication: the first need is a process-and-integration specialist familiar with appointment operations, not simply someone who can demonstrate a chatbot.
For industrial sensing, distinguish an advisory monitoring pilot from a control-system modification. Define the equipment, measurement locations, installation responsibility, permitted connectivity, maintenance review, and safety interfaces. A data analyst's ability to interpret a trend does not establish competence to install electrical instrumentation or approve a safety function.
AI advisors can help organize an approved requirements pack, identify unanswered questions, and compare proposed approaches. People confirm the operating facts, decide what is in scope, and authorize access. Confidential records should not be placed into unapproved tools to make discovery more convenient.
Ready to move on?
Proceed when an accountable owner agrees the intended result, essential skills, scope, constraints, and acceptance approach. Pause if the work is still described only as a technology purchase or if critical access and safety questions have no owner. The next step is to choose a channel that can supply the kind of help the brief actually requires.
These are reference points, not claims that this four-step guide reproduces a standard or establishes certification.
This guide explains a project-scaled approach, not a fixed package or a guarantee of results. Checks, responsibilities, and deliverables are agreed for each assignment. These scenarios are not client case studies. People retain selection, approval, and operating authority.