AEM Forms RFP Template

Before You Issue a AEM Forms RFP

Forms projects are portfolio projects. The unit of scope is not “an AEM Forms implementation” but the specific inventory of enrollment, onboarding and service forms you intend to digitize, in what order, with what conversion targets. RFPs that attach that inventory — even a rough one — get proposals you can actually compare; RFPs without it get placeholder estimates that all change later.

Accessibility is the compliance requirement most often left implicit and most expensive to retrofit. State the WCAG level you require, require it to be tested per form rather than asserted per project, and ask who on the vendor team owns it. The same goes for measurement: adaptive forms without analytics on drop-off points cannot be optimized, which defeats the purpose of the platform.

What the AEM Forms Sections Cover

• Form inventory banded into complexity tiers before pricing
• Fragments and themes that make form ten cheaper than form one
• Systems of record every submission must write to
• Approval routing and the point Acrobat Sign enters
• WCAG level tested with assistive technology, not a scanner
• Record of submission: generation, archival and retention

Writing the AEM Forms Scope of Work

Build the scope from a form-by-form inventory, and accept that assembling it is your job rather than the vendor's. For each form, record the number of fields and steps, whether it needs save and resume, whether it must produce a document of record, which back-end system receives the submission, and which regulations apply to it. Vendors price a twelve-field contact form and a forty-page mortgage application identically when the RFP says only that there are thirty forms. Group the inventory into complexity bands and say how many forms in each band are in phase one.

Specify the data integration layer separately from the form design. Form data models connecting to REST services, databases or record systems are usually the largest hidden cost, particularly where pre-fill is required, because pre-fill means reading customer data mid-session with authentication, error handling and privacy consequences. State for each integration whether the endpoint exists, who owns it, whether it is available in test environments, and what happens to a submission when the downstream system is unavailable. Submission durability requirements belong in the scope, not in a later architecture conversation.

Scope the document and signature side explicitly. Many forms projects need generated correspondence or a PDF document of record, which uses a different part of the product than the adaptive form itself and has its own template design work. If signatures are required, say whether they are simple electronic signatures or need a stronger assurance level, how many signers are involved, and whether the signing flow must support delegation and rejection. Approval workflow complexity should be described in terms of your real approval chains, including the exception paths people currently handle by email.

Make accessibility an acceptance criterion at the form level rather than a project-level assertion. State the standard, state that conformance is tested per form with assistive technology and not only with automated scanners, and say which party remediates failures found in testing. Then define done for a form as: it passes accessibility testing, it submits successfully to the named system under normal and failure conditions, it renders correctly on the device mix your users actually bring, and the analytics needed to see where people abandon it are live on the day it launches.

Requirements That Actually Separate AEM Forms Proposals

• Per-form accessibility evidence — require conformance to be demonstrated form by form with assistive technology on the real rendered output, including error messaging, focus order through multi-step flows and any custom widget the design introduces.
• Reusable architecture — ask what proportion of the later forms in the portfolio will be assembled from fragments, themes and templates built during the first ones, and how the vendor demonstrates that unit cost is actually falling.
• Submission reliability — require a description of what happens when the receiving system rejects or times out on a submission: whether data is queued, whether the customer is told, and how a lost submission is detected rather than discovered by complaint.
• Pre-fill and authentication design — ask how customer data is retrieved into a partially completed form, what identity check gates it, and how long partially completed data persists before it is deleted.
• Document of record — where a form must produce a durable record, require the template design, archival destination and retention rule to be described, since this is a separate build from the form the user sees.
• Rule complexity ownership — ask which conditional logic lives in the rule editor versus in custom code, because rules a business analyst can maintain are the difference between a form portfolio that evolves and one that needs a project every time.
• Abandonment instrumentation — require analytics on field and step level abandonment as a launch requirement rather than a later enhancement, since the optimization case for the platform depends on it.

Common Mistakes in AEM Forms RFPs

• ✕ No form inventory in the RFP, so every proposal prices a different imaginary portfolio.
• ✕ WCAG compliance asserted at project level but never tested form by form.
• ✕ Workflow and Acrobat Sign integration treated as configuration when your approval chains are genuinely complex.
• ✕ No conversion or completion-rate baseline, so the digitization program cannot demonstrate value.
• ✕ Fragment and theme architecture skipped, leaving every new form a from-scratch build.

• ✕ Counting forms rather than banding them by complexity, so a portfolio dominated by two long regulated applications is priced as if it were thirty short ones.
• ✕ Assuming the back-end endpoints needed for pre-fill and submission will be available in a test environment, when securing that access from another department is often the longest item on the critical path.
• ✕ Scoping translation as a copy exercise when localised forms change validation rules, address formats, legal wording and sometimes the field set itself for each market.
• ✕ Leaving the existing PDF and paper processes in place alongside the new digital forms with no retirement plan, so the operational savings that justified the project never arrive.

Questions Worth Asking AEM Forms Vendors

1. How do you sequence a forms portfolio — what criteria decide which forms are digitized first?
2. Show how you test WCAG compliance per form, and who on the proposed team owns accessibility.
3. Walk through a delivered approval workflow with Acrobat Sign, including exception handling.
4. How do you architect fragments and themes so later forms get cheaper rather than starting over?
5. What form analytics do you instrument, and show how a client used them to lift completion rates.

How to Weight the AEM Forms Evaluation

Weight the second form more than the first. Any vendor can deliver a single well-crafted adaptive form; what you are actually buying is the ability to deliver the twenty-fifth one cheaply. Evaluate the proposed fragment, theme and template architecture, and the stated unit cost curve across the portfolio, more heavily than the quality of a single demonstration. If a proposal prices every form at roughly the same rate, the vendor is not building reusable structure and you should ask why.

Give accessibility capability weight proportional to your regulatory exposure rather than treating it as a hygiene factor. Retrofitting conformance into a completed multi-step form with custom components is disproportionately expensive, and in regulated sectors an inaccessible enrollment journey is a live compliance problem rather than a quality issue. Evidence of testing practice, including who does it and with what tools, deserves more weight than design polish.

Score integration experience with your specific class of back-end system above general platform experience. Forms projects rarely fail at the form; they fail where the submission meets a policy administration system, a core banking platform or a records system with an awkward interface and a cautious owner. A vendor who has integrated with systems like yours will scope the error handling and the test environment access realistically, and that realism is worth more than a broader portfolio of simpler work.