Some stakeholders have expressed concerns regarding attachments not being available after cutover, so I wanted to put some information out there to address some of those concerns. This article deals with ‘attachments vs user-drawn maps’. A second article addresses “Google Map Gaps”. (Link)
At the end of August, the Business Rules Alignment Group (BRAG) announced that 'Attachments" to locate requests would no longer be a requirement in the new system. (Link) The Business Rules Alignment Group - who are responsible for all decisions about the direction of the new software and represent all 4 western provinces involved - decided that the information the new system provides them from the user-drawn map may eliminate the need to have additional attachments sent.
No one is disputing that site plans provide more accuracy for locators, and can provide some members (who receive attachments, and who locate on site, or use a manual screening process instead of automated response) with valuable information. However, it remains to be seen whether it is necessary or desirable to send attachments through the One Call automated process.
Maps as a One-Call function:
The purpose of One Call’s mapping process is to accurately notify members whose assets will be affected by user activity, not to provide detailed site information. The one-call process is moving in the direction it will have to take in the future to be efficient and accurate enough to keep up with rising demand, in a cost-effective and safe way. To that end, BRAG looked for new software with the following considerations:
1. Accurate location is mapped by the excavator - who has the best knowledge of where the digging is taking place
2. Accurate notification of members based on the map.
3. Provide location information in a format that reduces screening and manual processing time for members, providing a way for members to auto-respond to excavators more quickly (Cost reduction, efficient response times)
Reasoning behind removing attachments:
- We have data to support that user-drawn maps actually enhance safety and reduce damages - because the location was not interpreted by a contact centre agent who does not have first hand knowledge of where the work is being done.
- The new system does not just send members a picture of the dig site drawing; It sends an accurate spatial data file of the drawn site (which can import into the members own mapping systems), xy coordinates, and grid system references. Encouraging the use of the spatial representation of the dig site aligns with the members’ desire to reduce manual screening and increase efficient automation in their responses as volumes increase.
- The ticket goes directly from the website to the members, so there is no way to validate what the attachment contains prior to transmission. In some cases, the attachment contains a site drawing. In other cases, the attachment might be unrelated to the dig site, and/or could be a list of other sites that the user expects to be marked on a single request. These are some challenges contact centre agents face in the current system.
That said, the new system is fluid, and we will make changes as we move forward. If members who are not automating want to continue getting site maps, then we can put the option back into the software. (We are trying to improve, not put obstacles in front of users). The Pelican development team has agreed to leave open the option of attaching files. First, however, we need to collect data on the new system to see if it is actually necessary. This system is active in multiple countries (without attachments) and is successful without requiring information other than the dig-site shape file, so we want to evaluate it ‘as-is’ before developing a change that may not be required.