Use Wrike intake form for project briefs.

Hi Nelson Martinez! 

I am a Wrike admin for the Marketing team and we use request forms to kick off all our marketing campaigns. I wanted to share with you two ways in which we do this, as it depends on the team and nature of the request:

1. Including all the questions in the RF
This includes transferring all the questions that normally appear on a brief into a RF, making those necessary questions mandatory and using a variety of question types to capture the right information. We try to push the idea of "you should only be filling out a form when you have all the information for the campaign you want to run". 

• Pros: Variety of question types in the RF help us gather the type of info we need and the dynamic RF automation within the form allows us to create different "paths" depending on what the requester is requesting.
• Cons: The forms can get really long, sometimes people don't have all the information at the start and just blast through the questions putting answers like "TBD". 

2. Shortening the RF and giving an option for brief upload
This includes making a shorter form that captures any account-wide tracking information necessary, but leaves an option to submit their brief in whatever format they are most comfortable with. I usually include a single-option question like "How would you like to provide your brief?" and each option have a follow up question: a) I want to upload an attachment (follow up question is an Attachment question so they can drop a document) or b) I want to share a link to my brief (follow up question is a single line question so they can drop a link to their document). Sometimes with this option and if the form options create a blueprint, we tend to include a first task in the blueprints called "Submit brief" and auto-assign it to the requester who opened the form and set it to X days, giving them time to work on it but ensuring that all following tasks are dependent on its completion.

• Pros: shorter form aka less time for the requester to be IN the form, allows requesters to submit brief in whatever format they prefer.
• Cons: again, sometimes folks complete the form without submitting the brief in any format as there are ways to get around mandatory questions (i.e. for text questions, they can write something like "TBD" or "I'll provide it later").

Hope this helps :)

Our organization has! I think what is important is having someone that is very well-versed in request forms be the "owner" of it. The way that we create this for our team is by having the back-end, or the request form itself, be very complex, with many different routing questions and pages. By doing this, you can make the user-experience when filling out the form very simple. However, it takes a lot of testing and playing around with it to make sure it is built correctly with dependent questions & automations working the way that you intended. 

Our team absolutely loves it now that it is built, and it helps centralize all info to one spot, with all the tasks necessary to get started once the brief is completed populating based on the needs of the requestor of that brief! In addition, we made the questions that we want to be able to report on all custom fields, so as soon as the request is submitted, it's updating our overall department reports & dashboards.