A request for help from the community....

[Eric L]

Hi Everyone,

My name is Eric, and I’m a Product Manager here at ServiceNow.  I’m reaching out today to ask for your guidance.

I’m currently working to create a short new document that communicates what Service Operations Workspace does, and the value it provides.   My hope is that by the draft of the document with you that it will provide you with new ideas on how to get value from Service Operations Wo;rkspace and at the same time, you can provide me with feedback to make this more uccurate and useful for people  who have yet to migrate to Service Operations Workspace.

I’ve attached a working draft of the document to this article.  I’d hugely appreciate your feedback on what resonates, what's missing, and what might just be plain wrong...   You all are the experts in putting Service Operations Workspace into practice, and I’m grateful for any guidance you can provide.  

Please take a moment to download the draft document, and then share your feedback either here in the comments, or via direct message to me if you’d prefer to keep it confidential.

Thanks in advance for any guidance you can provide.

Eric

[Filip Vallberg]

Hi Eric,

Lifecycle
I posted this in the community some time ago regarding the operational lifecycle of SOW.
I also reached out to my SN pre-sales contact, who in turn asked the SN SOW Product Management how we are supposed to work with SOW when applying changes over time (SN request: ITS0001872).

The short answer I received is that we must manually reapply our changes each time ServiceNow delivers changes to a record that we previously had to copy due to customizations—meaning we never receive updates on it. As far as I know, there is no way to use update sets to capture differences between such records since, technically, they are entirely separate records.

This is not good, not at all. 

UX
The UX is for some reason, interpreted as messy and difficult to read. I can’t pinpoint exactly why, but something about it just makes the content harder to comprehend on screen (comparing to UI16).

This is not just my opinion. I usually ask my support staff what they think of SOW, and not a single one prefers it over UI16 (I’ve asked around 20 users).
I personally like the tab structure, but some support staff dislike it—especially since there is a limit on how many tabs can be open at the same time.

Configuring
SOW is also much harder to configure compared to UI16. Of course, there is a learning curve, but even after working with SOW for a couple of years, it still doesn’t feel anywhere near as straightforward as UI16.

Best regards,
Filip Vallberg