Anonymous
My feedback
25 results found
-
94 votes
An error occurred while saving the comment Anonymous
supported this idea
·
-
35 votes
An error occurred while saving the comment Anonymous
commented
(1aQ) Would you prefer to configure the date format on the request level or organization level?
(1aQ response1) Preference would be to have both options available.(1bQ) Why?
(1bQ response) Because if you are using the Ready-Sign link which typically is used for high volume, low touch documents, then it is more feasible to set at the organizational level. However, if you are sending out a customized signature request that typically won't be duplicated, it should have the ability to set at the request level.(2aQ) Will you constantly adjust the date format depending on recipients or it's a one time setting?
(2aQ response) Refer to answers given in 1aQ response and 1bQ response.(3aQ) What date format is ideal for you?
(3aQ response) European format. DDMMYYYY
(4aQ) Anything else that would help us to design and build a great solution to improve your experience
(4aQ response) Prioritize and adopt the document naming convention sooner rather than later. For high volume, minimal touch documents, the naming convention is an absolute NIGHTMARE!
Anonymous
supported this idea
·
-
24 votes
Hi, I am a Product Manager for Box's File System, I am looking for real world examples from your business needs where the waterfall permissions doesnt work. The more elaborate the example is the better it will be. Would you be willing to share?
Anonymous
supported this idea
·
-
3 votesAnonymous
supported this idea
·
-
10 votesAnonymous
supported this idea
·
-
64 votesAnonymous
supported this idea
·
-
5 votes
An error occurred while saving the comment Anonymous
commented
The ability to have a "stamp" (in Japan I think it is called a "hanko stamp") that can be used for anything within the signature process. Preferably, have it look like a seal of sorts, where it could have a company logo and then say "ABC Co. Legal" so the other internal company members know that this is an approved document for signature.
Anonymous
supported this idea
·
-
3 votesAnonymous
supported this idea
·
-
8 votesAnonymous
supported this idea
·
-
10 votesAnonymous
supported this idea
·
-
19 votesAnonymous
supported this idea
·
-
152 votes
We’re gathering feedback to better understand how merging signed documents and signature logs into a single file could improve your workflow.
Could you share your thoughts on the following?
- Would you expect all completed files, including attachments and the signature log, to be combined into a single PDF?
- Would you need only to merge signed files but not attachments nor signing log?
- What challenges have you faced with having them as separate files?
- How would merging the files improve your process?
Your input will be really helpful as we work on this feature. Thank you.
Best,
Box Product
Anonymous
supported this idea
·
-
6 votesAnonymous
supported this idea
·
-
7 votesAnonymous
supported this idea
·
-
15 votesAnonymous
supported this idea
·
-
7 votesAnonymous
supported this idea
·
-
15 votesAnonymous
supported this idea
·
-
13 votesAnonymous
supported this idea
·
-
9 votesAnonymous
supported this idea
·
-
8 votesAnonymous
supported this idea
·
Yes, there is a tremendous amount of value to have completed BoxSign fields filled out and then allow to become metadata. This is necessary for companies that use your BoxSign feature for high volume, low touch agreements (such as a NDA). For example, one typically tags within the document such things as the company name, the effective date, the signatory, etc. Within your enterprise level subscription, we should have the ability during the tagging stage to nominate the fields "company name" and "effective date" within the advance feature portion of the tag that says "yes - identify as metadata" and this could be done by the addition of simply checking a box so that this occurs upon execution. And then the collection of that metadata then becomes the naming convention.