How to brief enterprise admin software requirements

A brief describes the work, not the screens

To brief enterprise admin software requirements well, describe the processes the admin team runs today, the people and sites involved, the problems you want to fix, and the decisions already made, with real examples attached. Vendors and developers can propose screens and features. What they cannot invent is how your organisation actually handles a travel request or a room clash between two subsidiaries.

Briefs that list features, such as needs dashboard or needs approvals, tend to produce quotes that tick every box and still miss the point. A brief built on real processes gives the vendor enough to ask sharper questions and gives you a way to compare proposals fairly.

The brief is also an internal document. Writing it forces admin, finance and IT to agree how processes should work before money is spent, and that agreement is often where the most useful decisions get made.

Gather evidence before writing anything

Spend a few weeks collecting material. Export a sample of recent requests from email and chat, anonymised where they contain personal data. Copy the forms and spreadsheets in use at each site. Note where the admin desk gets the most questions and which requests stalled. Talk to a handful of requesters from different departments, not just the admin team.

This evidence becomes the appendix to your brief. A vendor who sees a month of real requests learns more than one who reads a page of summaries. Include the awkward cases: a request that touched several departments, a booking that clashed across sites, an approval that went to the wrong manager. They say more about your requirements than any number of routine examples.

Sections a useful brief contains

Keep the brief short enough to read in one sitting, with the detail in appendices. These sections cover what vendors need:

• Organisation outline: business units, sites and roughly who requests and who handles
• Scope: which areas are in, such as documents, requests, bookings or cross-team follow-up
• Current process for each area, step by step, including workarounds
• Problems to solve, each tied to a real example from the evidence
• Roles and permissions: requesters, handlers, approvers, owners and administrators
• Systems it must connect to, such as email, calendar, HR or finance
• Constraints: data handling, hosting preferences, languages and budget range
• Decisions still open, so vendors know where you want their advice

Separate must-haves from preferences

Mark each requirement as essential, important or nice to have, and be honest. If everything is essential, vendors cannot tell where to focus and prices rise accordingly. A requirement is essential if the system is unusable without it, for example routing travel approvals to the correct budget holder. It is a preference if a workaround is acceptable for the first phase.

Write requirements as outcomes where you can. A requester can see who is handling their request and what it is waiting on gives a vendor room to propose the best approach, while a specific screen layout may lock you into one vendor's design.

Phasing helps here. Many organisations do better starting with one or two areas, such as internal requests and bookings, and adding documents or cross-team follow-up once the first phase is in daily use. Say in the brief which areas you would phase and why.

Data, compliance and ownership questions

Admin systems hold personal data: staff details, travel documents, visitor records. State in the brief that the system must support your obligations under the Personal Data Protection Act and any internal policies, and confirm the current requirements with your legal adviser or the official source before finalising them. Ask vendors where data will be stored, who can access it and how it can be exported if you change systems later. Ask too about mobile access for staff at sites who rarely sit at a computer, and how the system handles leavers, including moving their open requests to someone else.

Name an internal owner for the project and for the system after launch. Vendors work faster with one decision-maker, and a system without an internal owner tends to drift from the process it was built for.

Sharing the brief and comparing responses

Send the same brief and evidence to each vendor and ask them to walk through two or three of your real examples in their response. That makes proposals comparable and exposes gaps quickly. Then invite shortlisted vendors to a session with the admin team and a few requesters; watching a vendor work through your examples live shows whether they understood the brief.

Fasttrade builds custom systems and also offers BukuAdmin for company administration, covering documents, internal requests, bookings and cross-team follow-up. A completed brief is a good starting point for that conversation, where Fasttrade confirms scope and availability.

Frequently asked questions