BRD Manager starts a requirements document from a catalogue of nearly 10,000 NetSuite features and leading practices, sorts every requirement into fit or gap as you work, and lets the AI assistant draw on your own team's knowledge.
Most requirements workshops spend their first weeks rediscovering what NetSuite does out of the box, usually by filtering the Blueprint spreadsheet and pasting lines into a workbook. BRD Manager starts from that instead. Pick the client's edition, region and target release, and the leading practices that apply arrive as draft requirements: a few hundred of them, grouped by process area, each already linked to the catalogue line it came from. Need one the seed didn't include? Pull it in from the catalogue with one click.
Then the real work starts. Your team checks each requirement with the client, edits it, removes it or discusses it, and adds what's unique to this business. The AI assistant can lead that discussion process by process and line by line, and the fit-gap updates itself the whole way through.
About 9,700 NetSuite features and leading practices across 60 process areas: a version of the Blueprint catalogue you can actually search. Filter by edition, region and market (AFA / Premium / NoAM, for example) and pull a line into the BRD with one click. Each line carries its description, talk track, dependencies and licensing. Without the catalogue, the AI has nothing to reason against. Without the AI, the catalogue is a spreadsheet nobody opens.
Every requirement is checked against the engagement's edition, region and target release and marked Standard, Standard + license, Version gap, Edition gap or Customization. Change the scope and the scores update. Set one by hand and your choice sticks.
Requirements grouped by process area and filtered by fit-gap result in one click. Each requirement has its own discussion thread, each catalogue line behind it has one too, and you can attach diagrams and documents to either.
Ask about a requirement and the AI already knows its priority, status, fit-gap result and the reasons for it, and the talk track. It can lead the discussion business process by business process, line by line. Nobody has to explain the project to it again.
Point the assistant at a knowledge base your team keeps in the CMS: what you've learned implementing NetSuite across verticals, in text, images and other media. Its answers draw on your firm's experience, not only on the catalogue.
Learn more →People can belong to several teams and work on several BRDs at once, across different projects. Custom requirements, the ones that need extra configuration or customization, sit beside the catalogue lines in the same document instead of in a separate tab.
A business requirements document is the least glamorous deliverable in an implementation and one of the most important. It decides what gets configured, what gets licensed and what gets built. It's usually put together from a template, a previous client's document and memory.
The usual tooling doesn't help. Filter NetSuite's Blueprint spreadsheet, paste each business process onto its own workbook tab, share the file, hold the meetings, paste in the notes, hold more meetings, then send it round for an approval process somebody improvised. The document lives in a file, the discussion lives in meeting notes, and the reasoning lives in people's heads.
That leaves it inconsistent in exactly the places that cost money later: a requirement marked standard that needs an add-on license, a capability promised that isn't available in the release the client goes live on, a customization nobody estimated.
BRD Manager shows all three while the conversation is still happening, not after the statement of work is signed. Your senior people stop spending discovery on requirements a catalogue already knows, and spend it on the ones that really are specific to this client.
An AI assistant on its own is nothing new. What it's connected to is the difference. BRD Manager's assistant already reasons against nearly 10,000 NetSuite features and leading practices. With retrieval-augmented generation (RAG), it can also draw on a knowledge base your team writes and maintains: how you've handled a process in a particular vertical, the workaround that keeps getting rebuilt, the questions that always come up in a given workshop.
The knowledge base is an internal site built in the SuiteResources CMS, with the same editor that runs our blog, so text, images and other media all go in. Point the assistant at it, and its answers draw on what your firm has learned over years of implementations, not only on what NetSuite documents.
Read more on how RAG, BRDs and the CMS work together in NetSuite implementations.
NetSuite ships two releases a year, and a catalogue that doesn't keep up slowly becomes wrong. So BRD Manager reads the release notes. The AI pulls out new capabilities, ignores the interface tweaks and bug fixes, and suggests additions.
Those suggestions go to a holding area, never straight into the catalogue. Each one cites the release-note text it came from and carries a confidence score, because it's something to check, not a fact. A person edits, approves or rejects each one before the catalogue changes.
The same rule runs through the rest of the app. Seeded requirements stay drafts until someone checks them. A scope change shows you what it will do before it happens, and it never removes a requirement anyone has worked on.
It changes nothing in NetSuite. BRD Manager produces documentation. It doesn't configure an account.
It doesn't replace the workshop. A seeded requirement is a leading practice, not this client's requirement, until someone has confirmed it with the client.
The fit-gap is only as good as the scope. If the edition, region or target release is missing, BRD Manager flags the engagement as incomplete instead of guessing.
The assistant is only as good as what it can read. Without a knowledge base it works from the catalogue and the requirement. A knowledge base adds your firm's experience; it doesn't make a suggestion a decision.
Catalogue changes are deliberate. Only editors can correct reference data, and nothing in it can be deleted, because too much depends on it.
Sign-off isn't a signature yet. Client approval of the finished BRD isn't a binding agreement today. We're considering DocuSign so that sign-off becomes a formal agreement on requirements and scope.
Scope, seed, verify, fit-gap, and what the client ends up holding.
How it works