Want to understand more about Citizen Services technology? Access our eBook “Transforming Citizen Services Through IT Modernization“
From the first day, Citizen Services is built to support all of our customers. Whether that’s the suburbs with 5,000 residents and comparatively simple needs, or perhaps a major city with an excuse for modern-day features.
With regards to the Service Request workflow, the way you accomplished this in the past was by applying a fundamental, built-in workflow that will meet most needs. For purchasers with an excuse for a far more flexible workflow, we’d integrate having a popular resource management system for example Dynamics 365 for Field Service or Cityworks.
Well, our customers have spoken, and we’ve took in. Within this release, we’re presenting more configurable and versatile workflows which are built directly into the machine.
To start with, customers can enable or disable the Dispatcher and/or Service Owner servings of the workflow. For instance, this could allow a workflow where Service Demands may go from the Reporter to some Service Engineer (without involving sales departments or managers).
In prior releases, Service Demands were routed towards the appropriate department or Engineers according to configurations made at design time. For instance, if your reporter visited “Potholes”, it had been pre-determined where this request could be routed in line with the configuration we performed during the time of creation.
What we’ve enabled within this release is the opportunity to route Service Request dynamically, according to exactly what the user inputs around the request form when creating the request.
For illustration, here is a Service Request Type known as “Road Feature”. Around the form with this Service Request Type there’s a needed field known as “Street Feature Type” in which the reporter must narrow lower the character of the request.
In Citizen Services, although we modify the shape according to which value the consumer selects (as described within the 1.3.1 Release Update), but we are able to also route the service request towards the appropriate group or engineer according to user input.
Within the custom workflow configuration below, you can observe the way we add conditions to define the way the service request type is going to be routed.
Notice within the screenshot above, not just may be the routing defined according to user selection, but we are able to also provide choices on how to assign the job to some specific engineer. We are able to by hand choose the engineer, assign according to which Engineer has got the least open assignments or by round-robin logic.
These power tools and options give a considerable amount of versatility for defining custom and dynamic workflows that may be focused on just about any requirement.
Another means by which we’ve elevated the versatility from the platform is as simple as adding additional Role and Permission Options.
Since its launch, Citizen Services has incorporated a Dispatcher role, which accounts for request management for example triaging, editing, assigning and shutting cool product demands. This role may be granted to some city’s answering services company sources, for instance. What we’ve been told by a lot of our customers, though, is the fact that their answering services company sources don’t always need all of the permissions and abilities connected using the Dispatcher role. Rather, they need a scaled-lower role that may add cool product demands with respect to constituents, and viewing or tracking the demands they’ve posted (but unable to edit or assign the service demands).
Presenting the “Reporter” role, which does exactly that.
This role enables organizations to assign permissions with only enough abilities, but little.
One factor our customers love about Citizen Services is when easy it’s to produce cool product Request Types—even when the person creating it’s no technical background. Well, now we’ve managed to get even simpler.
When designing a brand new Service Request Type, you may create one on your own, or clone a current Service Request Type after which edit it as being needed. This protects customers considerable time when establishing or making changes for their portals.
Sometimes jobs are too large for just one person to complete by themselves. Because of this, we’ve added the opportunity to assign multiple engineers towards the same service request.
This selection enables better tracking of sources and reflects a realistic look at how work will get done. In subsequent updates, we are adding sub-tasks so specific areas of the task could be allotted to each resource.
Finally, we’re always getting demands for additional language support. So we’ve added Portuguese to aid our buddies in South america, Portugal along with other Portuguese-speaking regions.
Stay tuned in! We’ll be posting more updates here soon!