Alternate Tools and Methods for Submitting Data

Effective 19 March 2017

(Use as Needed or Directed)


In case of issues arising with submitting data using the primary methods shown in the applicable program documentation, three alternatives are available.  Their use is shown in the order of preference. 


1.   Use the “Submit a Storm Report” Page              


2.   E-mail Message to the MKX Webmaster             E-mail Address


3.   E-mail Message to the MKX Comms Desk         E-mail Address

Subject Line MUST Include the text as shown below:


//WL2K R Weather Data (mm/dd/yyyy)


NOTE:     Due to the nature of Alternative 3, above, message size including all attachments is limited to 50 kilobytes (KB) per message.  This implies that most photos and other attachments cannot be sent through this method.  However, in order to help the office make/validate the decisions they need to make in as quick as manner as possible, it is the text that counts.  The photos can come later.


Please note that although the task (creating and sending a e-mail message as shown) is the same, the routing of the content is very different using the two alternatives above.




Format the message (and any attachments) exactly as shown per the guidance provided.  Deviations will result in mis-handled data and wasted time at the point of receipt.



Message Creation and Submission (Methods 2 and 3, Above)

Okay - so we talked about why things have to happen in a certain way.  How does it get done?  Since we are talking essentially about e-mail, the process is pretty simple.


1.     Create the message body and content in one of two ways.  Use the applicable program guidance for determining the criteria and format to use.



a.     Use this template to create a spreadsheet file:


i.              Complete the file as shown and attach the file to the message after removing the “first” worksheet. The first worksheet is not needed by the office


ii.             Attach the completed file to the message.



b.    In the body of the message. include one report per line using a comma between each element using the required criteria and report format.


Unless otherwise indicated limit each line/message 80 characters including any punctuation.


Examples (Using Convective Program Data and report format):


KG9MG,4" to 6" limbs broken from trees,447pm,43.789 88.686

WD9ABC,10" standing water,5:09pm,2.7 SE Darlington - Lafayette

KB9XYZ,3/4" measured hail,515am,5.0 W Rockdale - Dane



2.     Using the e-mail application of choice, create a e-mail message using the following guidance EXACTLY as shown below:


HINT:    The hyperlinks shown in section 2a below will auto-fill the necessary e-mail address and subject template detail in a new message via the user's default e-mail application.  Be sure to change the date text as needed in the subject line.


a.     E-mail Address

                                    Method 2 (MKX Webmaster)

                                    Method 3 (MKX Comms Desk)


                                    cc: to                               regardless of method


b.     Subject (Include ALL Text EXACTLY As Shown)

                                    Method 2 (MKX Webmaster)      Weather Data (mm/dd/yyyy)

Method 3 (MKX Comms Desk)   //WL2K R Weather Data (mm/dd/yyyy)



3.     Include the introduction contact information in case any additional information is needed.  Use this text as a template:


“The (‘attached file’ if using the template as described in 1a, above or ‘text below’ as described in 1b. above) are reports/datasets collected from (team name), a SulCom team.


I can be contacted at either phone ((nnn) nnn-nnnn) or by email at (e-mail address) if any additional information is required.”


4.     Send the message.


NOTE:  All elements (in other words, for a winter weather or convective weather report, the Time, Location, Condition, Source) per program guidance are necessary to consider the report valid, regardless of tool used.  Incomplete datasets contribute no value.


Data Collection Guidance


Unless otherwise directed, the required criteria and format are the same as the primary methods as outlined for the program being supported.


Note that there may be "out of the box" needs that may occur over time.  If those are truly required there will be guidance provided at the time of the need.


If the methods above are used, this is where the SulCom teams have a niche in adding value.  As SulCom teams normally set and run “nets” for data collection/accumulation purposes anyway, this is a perfect scenario for collecting/parsing/formatting/filtering data before it gets submitted to the office.


What is the Niche?

Multiple datasets (in the form of valid reports for convective and winter support, and as needed for other support as deemed necessary by the office) can be collected at a single point.  The datasets are then and submitted in a single message using either method above.


The use of available resources is (both in people and in bandwidth) is more efficient as less time is spent on sifting through e-mails that contain single data sets.


Example:       Instead of the office receiving, for example, 50 messages each containing a single report/dataset, the office can (in theory) receive a single message containing 50 reports/datasets.


Let's say that the time required to review a message takes 15 seconds.  Multiply that by 49 and divide by 60, and that means over 12 minutes (12 minutes and 15 seconds to be exact) can be saved in reviewing messages.


The time saved may not seem like much depending on perspective, but in the tactical incident support business the time savings is considered a big win and the time saved can be used for other tasks that add value in other areas.


Formatting the reports/messages as directed makes parsing and handling of the data much easier on the receiving end as the datasets arrive at the point of receipt in a form that facilitates efficiency.



Okay – So Why Have These Plans in Place?


No method or tool is impervious to unanticipated issues.  Primary tools are great for the desired results the majority of the time, and because of the features those tools have, they are preferred.  Despite this, there are times when those tools may not be available but the need to achieve the goal is still required.


Given the desire to satisfy the needs of the customer regardless of scenario, it is important to change tools as needed so the tasks at hand can be achieved with success and ultimately with minimal disruption. 


Agility is a now a requirement where it has been a luxury in the past.  In this regard, from the perspective of the individual volunteer, understanding the nature of the issue itself (how "it" happened, "why" it happened, etc.) and understanding why there was a need to “switch gears” is important, but it is not a primary goal.  Moving from “where we are” to “where we need to be” in a timely, efficient manner in addition to getting the job done right and done well (considering safety, accuracy and method in that order, but ultimately with all three in mind) is the goal.


Contingency plans come in many shapes and sizes depending on the desired result.  In the SulCom programs a successful contingency plan maintains continuity of operations with minimal impact on achieving the overall goal and with safety and accuracy in mind.  It is understood that there may be trade-offs in throughput, performance and other “nice to haves” so a thorough evaluation of priorities with customer input is also necessary.


The primary tools can capture most, if not all the necessary elements of the dataset automatically.  This assumes the person submitting the dataset sets their app(s) and devices in that way.  However, in executing contingency plans it is important to understand that tasks may require more “touch” to complete successfully.  Some of those “nice to haves” will be placed aside for a period of time as well.


In a nutshell, in development and execution of a good contingency plan in SulCom, the tools may change, but the process and the high priority requirements remain the same.