Types, Forms, Services: same number of each?

I suppose you could reuse the same form for various services, but in that case I would *not* include the "Service" field on the form at all, as that already gets populated via the connection that services have with the forms they are using. If you were to include the Service field specifically on a form, and give it a default value of some service other than the one currently being requested, it would override the service the user is requesting and place the default value of the form on the created ticket. Hopefully that makes sense, but in general I'd steer away from including Service as a field on the form. It's a baked-in field that shows up on every ticket regardless of whether it is included specifically on the form, so there's no need to have it on forms, especially ones that aren't configured to be used from the TDNext end of the tool.

Greg,

Regarding using Questions vs. the advisory group... I *do* follow the entire Questions category and wish more people did also. I prefer it to the advisory group because the emails from the advisory group do not include the topic, while the Questions emails do. I realize this isn't a "conversation forum" so I hope no one minds that I interjected this comment!

Karen

Thanks again Mark!

Now this helps! Even though I set up the service with the form, I thought I had to put the field on the form also. This type of information is great to have. Have any more? :)

Karen -

I think I'll do the same and I'm glad you interjected your comment!

Mark,

Thanks for the extra info. I thought it would have been an easier-type answer because I thought everyone was reusing a form on various services. Hiding the "service" field on the form so that customers don't see/interact with it doesn't lead me to think I could reduce the number of forms I use because even though the field was hidden, the field still exists and has a default value. I thought the answer would be along the lines of creating a more generic form and creating automation rules so that when the ticket gets created with (whatever) the automation rule kicks in and does (whatever). I don't use many automation rules yet so I was thinking there was an easy answer that involved things I don't know much about.

I am open to people at other institutions chiming in with their solutions but I don't think people generally read the questions area unless they are searching for an answer. I might post the question on the Service Management Advisory Group feed where it might get pushed in front of people. As for process consulting, I'll let you know.

Thanks!

For your item 1) I can say that in general if you had things the Client shouldn't be interacting with on the form, just make those fields "Hidden" for the Client setting and "editable" or "editable and required" in TDNext so the techs can interact with the fields as needed after receiving requests.

Grouping similar services into a single service would eliminate the need for additional forms, then you could utilize cascading attributes to let the client select the exact item they're needing to request.

I think for 2) you could benefit from even just an hour or so of process consulting as that will be more of a best practice type thing that a consultant would be able to offer a few ideas on.

Let me know what you think about that.

Greg,

It sounds like possibly you could benefit from a block of time with a process consultant from TeamDynamix to go over some options that you might consider for optimizing services/forms/types for both portal and TDNext usage.

If you're interested I could refer this to your account manager to follow up and facilitate that engagement?

Otherwise I could request Professional Services to take a look and offer you some recommendations that have worked for their other customer. In general we do not have a list of recommendations that *might* work, as each organization typically sets up their services and forms in a way that is most useful to their needs, so a Services representative would be best suited to giving you some ideas to think about for the items you have asked here.

Sincerely,
Mark Sayers
TD Support

Great! I can figure out how to reduce the number of types (especially since we don't use SLAs yet). I understand the concepts of cascading attributes to limit the number of forms needed but I'm unsure on a couple of details:

1. Our forms have titles, services, and types that are defaulted to the values associated with the service. Our technicians can change the values (TDNext) but I don't want to force our customers to do that (TDClient). How can I reduce the number of forms but make this work on the TDClient side?
2. Even though our technicians can change the values in TDNext, it seems to be hard for them to change all the values that need changing. We use desktop reports to catch the tickets that aren't set right. Is there a better way to do this - preferably limiting the number of fields that the technicians need to change?

Hello Greg,

You certainly do not *have* to have any more forms than you really want to use. With the existence of forms now and things like cascading attributes, it is hopefully possible for you to consolidate forms and services as much as possible to trim out things that might have been almost a duplication of effort.

Because of the way conversion to 9.5 happens you *do* end up with a form for each ticket Type, but you can remove those forms or do whatever you want with them to make them as useful as possible to your organization or the department who's ticketing app it is. Trimming down types and forms certainly would not hurt anything, and it would probably make things like automation rules and whatever work more efficiently if it didn't have so many of them to filter through when evaluating each new ticket.

Sincerely,
Mark Sayers
TD Support