Estimated delivery date on requests | Community
Skip to main content
New Participant
May 25, 2023
Solved

Estimated delivery date on requests

  • May 25, 2023
  • 3 replies
  • 1440 views

On our requests forms, is there a way to calculate a field to show requestors an estimated date of when a deliverable could be completed? For example, if a requestor selects that they want to send an email, we want to show an email would take x number of days. And the soonest date the email could be sent would be July 5. We want it to exclude weekends and ideally holidays. 

 

The problem is that we have a bunch of people requesting assets, but they don't understand the typical timelines on how long those items take to create. If there is a way to give visibility to the requestor, it would help them have a better idea when those deliverables could be completed. 

 

We've had some ideas, but can't figure out if it's possible:

  • calculating fields based upon a template
  • Using the default schedule in the system for calculations
  •  

 

 

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by SarahWilkersonCA

Like you, we would love to be able to calculate on the fly without clicking the submit button or populate one field based on another entry on the fly and we didn't want to create a custom form per request type (just too many).  We opted to do a spreadsheet that is housed in our internal system and add a URL inside the custom intake form that links to this document.  This way the requestor can easily link to the document and the system admin doesn't need to maintain dozens of custom forms or display logic. 

3 replies

SarahWilkersonCAAccepted solution
New Participant
May 30, 2023

Like you, we would love to be able to calculate on the fly without clicking the submit button or populate one field based on another entry on the fly and we didn't want to create a custom form per request type (just too many).  We opted to do a spreadsheet that is housed in our internal system and add a URL inside the custom intake form that links to this document.  This way the requestor can easily link to the document and the system admin doesn't need to maintain dozens of custom forms or display logic. 

ElysiaYuAuthor
New Participant
May 31, 2023

That is a great workaround. Thank you for sharing!

ChrisStephens
New Participant
May 30, 2023

As part of the request queue, could you configure each deliverable type to be it's own queue topic? This would let you set a default duration automatically for each object type, and you could have a custom form for each deliverable, and on the form you could include a description field/note about what the timeline will be for that milestone.

ElysiaYuAuthor
New Participant
May 31, 2023

That would be a good idea! Unfortunately, we have other teams using Workfront that it would make the queue topics too messy. Thank you for sharing the ideas!

 

Doug_Den_Hoed__AtAppStore
New Participant
May 25, 2023

 

Hi Elysia,

 

There's a wide spectrum of ways to help set Requestors expectations for turnaround time:

 

  • At the most complex and accurate end, revealing the Templated / Assigned / Planned results to them would certainly be transparent, but does take time to Route / Convert / Approve / Assign / Vet / Reveal, so might be overkill.
  • In the middle, the idea of presenting some rule of thumb "best possible" calculated parameter is tantalizing...but since such calcs only run after the Request is submitted (and again, would be subject to change), might be Too Late
  • On the practical end, to at least start setting expectations, one simple and highly visible approach would be to add a suffix to each such request indicating the approximate turnaround time (e.g. "Basic Email (3-5 Business Days)"), which would remind users as they make the request what's realistic (and what's not)

 

Regards,

Doug

ElysiaYuAuthor
New Participant
May 31, 2023

Good points that I didn't originally think about! These are some workaround ideas that I'll run by the team. Thank you for your response.