The first conversation with a data vendor often goes in circles. The buyer describes what they need in general terms. The vendor asks clarifying questions. The buyer answers some, defers others, and the conversation ends with both sides agreeing to follow up. The follow-ups produce a proposal that the buyer feels does not quite reflect what they wanted, and a second round of conversations tries to close the gap. Two weeks have passed and the project has not started.
The cause is almost always the same. The brief was not specific enough to scope against. Both sides spent the first conversation trying to make a brief that did not yet exist. A scopable brief takes more upfront work to write but produces faster proposals, fewer revisions, and a project that begins with clarity rather than uncovering misunderstandings in the middle of delivery.
Why vague briefs produce vague proposals
A vendor cannot produce a specific proposal from a general brief without making assumptions. Those assumptions might be reasonable or unreasonable, but they will not match the buyer's actual requirements exactly, and the gap surfaces when the proposal lands and the buyer reads things that do not quite reflect their intent.
The buyer then asks for revisions, the vendor revises, and the iteration cycle continues until the proposal looks acceptable. This works, but it consumes weeks. It also creates room for misalignment that persists into the project, because the proposal evolved through compromise rather than from a clear specification.
The seven things a good brief contains
A brief that can be scoped against in a single conversation covers seven specific dimensions. Some of them require the buyer to have done internal alignment work before approaching vendors. That work is part of the cost of running a data project well.
The business objective the data is supporting. Not the technical task. The reason this data is being collected. A model that needs to be deployed for customer support in three markets. A robot that needs to navigate a specific warehouse environment. A classifier that needs to flag fraud in a specific transaction pattern. The vendor needs this to evaluate whether their approach actually serves the goal.
The model use case. What kind of model is this data training, at what stage of development, with what input and output. The vendor does not need to know the architecture. They need to know enough about the use case to design collection that fits.
The data type and modality. Speech, image, video, text, or some combination. Specific format requirements. Resolution, frame rate, audio quality, file structure, naming conventions. These are details the buyer's engineering team usually has and that often do not make it into the initial brief.
Target volume. How many records, hours, images, clips, or whatever the unit is. A range is acceptable if the volume is not yet locked, but the range needs bounds the vendor can plan against.
Demographic specifications. The dimensions that matter for this project: language, dialect, accent, geography, age, gender, skin tone, domain expertise, anything else relevant. If demographic diversity is important, it has to be specified or the vendor will default to whatever is easiest to source.
Quality criteria. What good looks like. The acceptance threshold, the quality metrics that will be used, how edge cases should be handled, what the vendor should do when they encounter ambiguity. This is often the section that is left vague and is the single most common source of late-stage disputes.
Timeline and cadence. When the data is needed. Whether it is one delivery or rolling batches. How fast the vendor needs to ramp. This determines whether the project is operationally feasible at the volume and quality requested.
The time spent writing a clear brief is the time saved on revising proposals, renegotiating scope, and untangling misunderstandings mid-project. It is the highest-leverage hour in the entire engagement.
What the brief does not need to contain
Briefs sometimes drift into territory that is not useful to share with a vendor and slows the conversation down.
The brief does not need technical model details that are not relevant to data collection. The vendor does not need to know the architecture, the loss function, or the optimisation approach. They need to know what the model will do, not how it will be built.
The brief does not need to anticipate every edge case in detail. It needs to acknowledge that edge cases will exist and specify how they should be handled (flag for review, resolve by best judgment within stated guidelines, or escalate to the buyer for decision). The vendor will surface specific edge cases during the work.
The brief does not need to specify the vendor's internal workflow. The vendor will propose their process. The brief specifies what outcomes the buyer needs from that process.
What to do if you cannot fill in all seven yet
Some buyers come to the vendor conversation before all seven dimensions are fully known. That is fine, and a good vendor can work with it, but the missing items need to be acknowledged rather than papered over.
If volume is uncertain, share the range and the basis for it. If demographic requirements are still being decided, ask the vendor to propose options. If quality criteria are not yet defined, ask the vendor to share what they typically deliver and have the conversation about whether that meets the buyer's needs. The point is to surface the gaps rather than hide them, because gaps that surface in the first conversation get resolved in the first conversation. Gaps that hide in the brief tend to resurface as problems mid-project.
Business objective the data supports. Model use case in non-technical terms. Data type, modality, and format requirements. Target volume with bounds. Demographic specifications across all relevant dimensions. Quality criteria with handling rules for edge cases. Timeline and delivery cadence. Acknowledged gaps in any of the above.
How ConsultBae approaches this
When a client comes to us with a brief that is not yet scopable, we work with them to fill it in before we propose. Sometimes this means helping them think through demographic specifications they had not yet defined. Sometimes it means walking through quality criteria options based on what we have seen work in comparable projects. Sometimes it means flagging that the timeline they are working with is not realistic for the volume and quality they have asked for, and discussing the trade-offs honestly.
The result is that by the time we send a proposal, both sides understand what is being scoped, what the constraints are, and what the project will involve. The proposal is something both sides can act on, not the start of a negotiation about what was meant. That clarity is worth the upfront time it takes to build.
Amitt Agrawaal is the Founder of ConsultBae. He has spent six years building ConsultBae's operations across recruitment, e-learning, and AI data collection across 100+ countries.
Scoping a data project?
ConsultBae helps clients write the brief when they need to, because the work goes better when scoping is clear. Let us talk.
Talk to us
