What to Include in an Internal Automation Brief Before You Talk to Vendors

There's a common scenario that plays out when a business decides it wants to automate something. They reach out to a development agency or a software consultant, hop on a discovery call, and spend the first hour answering questions they should have already answered internally. The vendor is patient. The business stumbles through it. By the end of the call, nothing has really been decided and a follow-up is scheduled to cover what should have been covered in a brief.

This costs time. It also sets a bad dynamic for the relationship, the vendor ends up defining the project rather than delivering your vision of it.

A well-prepared internal automation brief changes all of that. It puts you in control of the conversation, shortens the project timeline, and dramatically reduces the risk of scope creep. This post walks through exactly what to include in one.

What an Automation Brief Is (and Isn't)

An automation brief is not a technical specification. You don't need to know how to build the thing. It's a business document that captures what you need, why you need it, what constraints you're working within, and how you'll know if it's worked.

Think of it like a project charter for your automation initiative. Any competent vendor or developer should be able to read it and have a clear picture of what they're being asked to deliver.

Featured

Stop Letting Vendors Define Your Automation Project

A weak or missing brief leads to scope creep, cost overruns, and misaligned solutions. Get clarity on objectives, constraints, systems, and KPIs first so you can control the conversation—not react to it.

Build a Stronger Automation Brief→

Section One: Objectives

Start with the why. What is the business problem you're trying to solve? Be specific. Not "we want to be more efficient" but "we want to reduce the time it takes to onboard a new client from two weeks to three days" or "we want to eliminate the manual step of copying order data from our CRM into our accounting software."

Good objectives are measurable. They describe a current state and a target state. They're specific enough that anyone reading them can understand what success looks like.

Write two to four clear objectives. If you have more than four, you might be scoping two separate projects.

Section Two: Constraints

Every project has constraints. Document them honestly. Budget is an obvious one, give a realistic range, not a number plucked from the air. Timeline matters too. If you need something live before a specific date, say so upfront.

Team constraints are just as important. Do you have an internal technical resource who will need to maintain this after it's built? Or will you need the vendor to own ongoing support? Is there a key person who will be unavailable for part of the project? These things affect how a project is scoped and priced.

Not documenting constraints is one of the main reasons projects overrun. The vendor makes assumptions to fill the gaps. The assumptions are wrong. Everyone is surprised.

Section Three: Data Sources and Systems

List every system that is involved in or affected by the automation. Your CRM, your accounting software, your email platform, your project management tool, your e-commerce platform, whatever is relevant. Note whether each system has an API, and whether you have the technical access and credentials needed to integrate with it.

This is important because integration complexity is one of the biggest drivers of project cost and timeline. If a vendor doesn't know what systems are involved, they can't give you an accurate quote. If they give you a quote without this information, it's likely to change significantly once the reality of your tech stack becomes clear.

Section Four: Users

Who will use the automated system once it's live? Be specific. Name the teams and roles. Describe their technical confidence level honestly; a team of non-technical operations staff will need a very different interface than a team of developers.

Also, document who currently owns each process being automated. Ownership is important for two reasons. First, it determines who needs to be consulted during the build. Second, it establishes accountability for the system once it goes live.

Section Five: Edge Cases and Exceptions

Every process has exceptions. The customer who always pays with a non-standard method. The order that comes in from a third-party platform, the main system doesn't recognise. The approval sometimes needs to go to a different person based on the deal size.

These edge cases are the things that most automation briefs miss, and they're exactly the things that make builds complicated. Document every exception you can think of. Ask your team. They'll know them because they handle them every week.

If you miss them in the brief, the vendor will discover them during the build and raise a change request. That costs time and money. Getting them in the brief upfront is always cheaper.

Section Six: KPIs

How will you know if this worked? Define the metrics upfront. These should map directly to your objectives. If your objective was to reduce client onboarding time from two weeks to three days, your KPI is onboarding time. Measure it before the build starts. Measure it again at 30, 60, and 90 days after launch.

Without KPIs, projects get declared successful or unsuccessful based on feeling rather than fact. That's bad for everyone. It's bad for the business because you can't learn from it. It's bad for the vendor because their work can't be properly evaluated.

Why an Automation Audit Makes Brief-Writing Easier

If you've never had to write a document like this before, it can feel daunting. You know the business from the inside but articulating it clearly in a structured format is a different skill.

This is one of the most practical benefits of running an automation readiness audit before briefing vendors. The audit process generates most of the information you'd need for a brief. By the time you receive your findings report, you have a prioritised list of opportunities, a mapped view of your processes, and a clear picture of your data and systems. Turning that into a vendor brief becomes straightforward.

Businesses that brief vendors after an audit consistently get better quotes, faster timelines, and fewer surprises mid-project. The upfront investment in clarity pays for itself quickly.

Featured

Apply for the free Automation Readiness Audit

An audit from Nexur gives you the evidence base you need before you talk to anyone.

Apply Now→

Want a head start on your automation brief? An audit from Nexur gives you the evidence base you need before you talk to anyone. Apply for the free Automation Readiness Audit →