Electronic claims transmission

To the best of our knowledge, Maytag was the first company to pioneer electronic claims. They designed a file-format into which each claim must be fit. Much like a paper claim has boxes to fill-in, their electronic file format had specified “fields.” The notion was you make a file (or, better yet, your software does it for you) that puts appropriate text into each field within the file. You can add as many claims to the file as wanted, then must “upload” the file to a designated location. Early on, Maytag designated a particular electronic bulletin board as the place where such files were uploaded to. Later, as websites proliferated (and as other entities began accepting electronic claims), the uploading function shifted to website interfaces as particular to each such entity (each had its own specified file-format, too).

To make the transition within our Finished-Forms interface, from merely printing the contents of our on-screen NARDA to instead saving it to a file (and within a particularly-specified format), was quite easy — in principle, at least. It’s simply involved picking a different place and format for the output. Everything else stayed the same. For such reason, our Finished-Forms interface conveniently became the perfect platform for launching electronic claims. Aside from the actual functionality, we simply had to add another action button: instead of solely “Print,” we added a “Transmit” button.

In principle, the entire concept is that simple. When you’re ready to claim on any warranty job, just let the system auto-fill its info to the on-screen NARDA, check for any needed edits, then click on the “Transmit” button, and follow further prompts. Such further prompts will ask you to identify to whom the claim is going (has to know to format correctly for that entity), and for some will ask you to choose among optional methods.

In regard to this latter, Rossware pioneered an advanced form of electronic claims transmission. To us, it seemed a little stupid that you should have to first save claim information to a file, and then afterward still have to manually upload it. With some of the processors (in particular, ServiceBench and ServicePower), we worked out “direct” methods, via which ServiceDesk can directly hand-off each claim— thereby avoiding any need for you to upload a file after the fact. It’s much more efficient and modern. Nevertheless, the old methods are still optionally available even for those processors, and are the only methods available for others.

The above four paragraphs provide the entire conceptual framework as needed to enable your successful entry into the hyper-efficient world of managing your claims electronically, and as direct-integrated with your management software. In principle, such understanding will allow you to immediately escape the inefficiency and drudgery of manually filling-in warranty claims on-line. Essentially, ServiceDesk is going to be accomplishing the fill-in there for you — though by putting all the claim information in a packet that is then processed (for fill-in there) by the entity to whom it’s handed off.

Aside from such general principles, we’ll now discuss a few specifics.

If you do warranty work, each involved manufacturer is a client. You should create an appropriate template for each in your QET interface [see page 57]. This is important, because when ServiceDesk fills-in that on-screen NARDA for you (as applicable to any given job) you want it to be filled-in as optimally and perfectly as possible (it means less for you to fix via manual editing). If you have an underlying QET template appropriately setup, ServiceDesk will be able to grab (and appropriately insert to the NARDA) information as appropriate to the underlying manufacturer (things like default labor amount, your servicer account number with the manufacturer, etc.).

It’s also important to assure ServiceDesk knows how to connect from a particular JobRecord to a particular client’s QET. To assure this, you need to know the method ServiceDesk uses when making the attempt. Quite simply, it looks in the Customer-Name box (very top) of the JobRecord as being loaded to the NARDA. It extracts what we call the first-phrase of text, which is defined as any such text as begins at the front of the line and continues until reaching a group of two or more spaces. It takes that text and goes looking in your QETs for a match, either to a QET name or to the two-or-three-letter abbreviation as there specified for same. If it finds a match to either, it goes “Aha, I have a match,” and figures info from that template should be used to guide auto-fill (for such boxes where it’s appropriate) to the on-screen NARDA.

Based on the above, please realize that for optimal (i.e., labor- and frustration-minimized) usage, it’s important to assure you’ve setup QETs appropriately, and that each applicable JobRecord is appropriately configured to connect to same.

There are several paths for getting into the Finished-Forms interface.

As prior alluded, you can open the form directly via its quick-key shortcut (Alt-F4; access is also available via mouse-click in the MainMenu). Once you’re in the interface, there’s a simple box where you can type any ServiceDesk invoice/ticket number, then load into any of the optional form types.

As one potential work scenario, then, it’s possible you could have a stack of paper tickets that need claims. With the stack on your desk and near your left hand, go to the Finished-Forms interface, pick NARDA as your form type, then type the first ticket number, and hit Enter for load (or click on the Load button, if preferred). ServiceDesk then loads information into the form, you scan and make sure all is appropriate to the claim (editing for needed changes, if any), then click on Transmit, and pick the entity/method of conveyance. With that first claim done, flip over the first sheet on your desk and proceed to the next — working in significantly rapid fashion through the entire stack, to complete your claims. (Don’t forget: for any claims simply saved to a file, eventual upload is needed too).

That’s one potential approach, and would be particularly suited if you’re still using paper, and if there’s a person who’s directly responsible for the claims process but not directly involved with other processes that might otherwise be integrated.

For an example of the latter, suppose you’ve decided to organize your processes such that an office person is doing PostVisitReports (using the Type-II interface) on behalf of techs based on paper tickets they’ve turned in from the prior day’s work. Suppose the same person is also authorized to handle claims submission. In this case, the person would want to have the PVR form’s “Link automatically to post-completion tasks” box checked [see page 116]. Upon finishing the PVR in connection with a warranty job that was itself complete, she’d then auto-link to the Finished-Forms interface. In this context, there’d be no need to provide it with a ticket number, since it already would have been passed as part of the linkage. As in the other described case, even so, she’d pick NARDA as the form type, ServiceDesk would auto-fill, she’d proceed with the claim, then it would take her right back to the PVR Type-II form for the next PVR item.

In the first context as described, your operator is doing claim, claim, claim, all from within the operative home of the Finished-Form interface. In the second, she’s doing PVR-then-claim, PVR-then-claim, all from within the operative home of the PVR Type-II interface. Depending on your organization and circumstances, one may be more efficient, or the other. At any rate, there’s no need to strictly pick: you can go back and forth, at will.

Still another context would involve looking directly at a JobRecord on which you know a claim needs to be made. You can pick that form’s “Print Options” button, and from actual options as then presented pick FinishedForms, from there NARDA, then make the claim. The main point is, there are many options, and what’s most efficient depends on the circumstances.

As a final example, suppose you’ve implemented SD-Mobile with your techs, and you’ve gone rather paperless, so as a rule are not getting paper back from them. One method to facilitate appropriate Post-Completion management, in this scenario (both sales entries and claims submissions), is by using the JobsPerusal form (shortcut is Shift-F7). There, pick the “Completed” category, and rotate through each job in such status, doing such post-completion management as the situation demands. In this scenario, there’s no need to worry about PostVisitReports (already done by the tech via Mobile), but you’ll need at least to make a SalesJournal entry, plus a claim if applicable. If the latter, choose “Print Options” (as an applicable JobRecord is selected) and proceed exactly as otherwise described above — except please also note you can integrate to the SalesJournal entry from that FinishedForms/claims interface (further described shortly).

Whenever a job is first “loaded” into the Finished-Forms interface, there’s a ton of underlying work done by the system. Besides looking for information pertinent to a particular warranty client that should be filled in, for example (see discussion above regarding use of QE-Templates), it looks in your inventory-control system to find any parts as used from inventory that should be filled in. It looks in your parts-process system to find any parts as special-ordered that should be filled in. It looks in your funds-control system to find any monies received, as should be filled in. It looks in your PVRs to find any tech date and start/end-times that should be filled in. And it looks in any JobRecord-attached UIS to find model, serial and purchase date to fill in.

In short, it looks in all the myriad places that ServiceDesk has collected information, as relevant to the job as you’ve used its multifarious mechanisms to most conveniently manage all connected processes. It ties them all together via automated fill-in to whatever FinishedForm you pick (where it’s a warranty claim, of course, you’ll pick the NARDA). Among other things, please realize this means you are going to achieve maximum benefit when you are fully using all those other system according to their intended design. Anything less, and your benefit will be reduced.

For most warranty processors (and if you’ve done all the above appropriately), the auto-filled text will be all (or in some cases nearly all) that’s needed for successful configuration of your claim. Common exceptions involve such matters as an extra mileage or extra labor charge, or where a manufacturer requires provision of special codes. Regardless, the general idea is that a claims operator should review what’s presented in the on-screen NARDA, and (prior to picking Transmit) add any such edits as might be needed for successful configuration.

In regard to editing what’s presented, you’d probably not like it if you put a bit of work into refining the initial auto-fill, and such work was not saved. For this reason, FinishedForms mechanisms will automatically save whatever edit state you have created, in any FinishedForm and as connected to any particular underlying ticket. It does this behind the scenes, and without even your awareness. The fact will be evident only later, if you go back to the Finished-Forms interface, and with a ticket number specified on which there was a prior such save. In such a case, ServiceDesk will convert to bold any radio button as associated with a form type on which there was a prior save:

If you pick to load such a form type (i.e., one on which there was a prior edit-save for the ticket in question), ServiceDesk will not immediately do the “search-within-all-its-data-elements-for-fill-in-to-the-form” function. Instead, it will give you the option as to whether you want that (aka “a fresh import”) versus a re-load of the form in the state you last edited it.[1] Please understand that if you pick re-load, that’s exactly what you’re going to get. In other words, even if ServiceDesk has newer information than existed at the time of that last edit (e.g., new parts special-ordered), it’s not going to fill them in on a re-load. If you pick a re-load of prior edits, that’s exactly what you’ll get (text in exactly the state you last left it). On the other hand, if you pick fresh import it’s going to ignore your prior edits and do an entirely fresh import. This is a place where there’s no “best of both worlds.” It’s one or the other.

When you’re using the newer, direct-transmission-of-claims methods, there’s not much you can do wrong in regard to direct hand-off of the claim. The first time you do such a process from any station, you’ll be required to provide your credentials (ServiceDesk needs them to talk directly on your behalf to either ServiceBench or ServicePower), and from that point forward ServiceDesk assures accurate hand-off of the claim info as assembled in your NARDA.

Where you’re using the older methods, though (sometimes called “batch upload”), the burden remains on you to upload a claims file after you’ve assembled claims into it. Such older methods are all that’s available (at least as of September ’11) for processors other than ServiceBench and ServicePower, so there’s a good chance you’ll still need to be using them. We want to advise you here on the easiest/safest method of managing such files.

Whenever in ServiceDesk you go to save a claim to a file (you’ll have gotten there from the FinishedForms NARDA by clicking on the Transmit button, then picking a non-direct-method option), ServiceDesk will open the standard Windows Open-File dialog box. It will default to a particular location and filename, the latter being specific to each processor. While you’re perfectly free to pick a different location and name, we suggest (for simplicity) you accept the default. When you make the very first claim as applicable to a particular processor, the file will not already exist. ServiceDesk will create it as you put that first claim into it. When you go to do the next claim for the same processor (and if you accept the default offering to the same file), ServiceDesk will tell you the file already exists, and ask if you want to add your present claim into the file (append), versus replacing what’s there with your present claim (replace)?

Here is the strategy we recommend:

As you’re making claims during the course of any given day, work to build multiple claims into each file as applicable to each batch-upload processor you’re working with. Suppose in the course of a day you will make three Dacor claims, for example. With the first such claim of the day, we suggest starting with a fresh Dacor claims file (thus, if one already existed when making the first Dacor claim, you’d choose to replace what was already in that file). With each such subsequent Dacor claim, choose to add to (or append) what’s already there. In this manner, by the end of your work for that day you will have accumulated all of the day’s claim work, for Dacor, in that particular file, and now you can upload it. Same with your Fisher Paykel file, and so on. The next morning start fresh in each relevant file, building it throughout the day for the evening’s upload, and so on.

In regard to the above, please note we have not suggested you uniquely name a file for each day’s work. Though there are some companies that do this, by our thinking that’s too much of an annoyance, and there’s no real need. We prefer the concept of using the same file set (one for each processor involved with batch claims) over and over. If you happened to mistakenly replace a file prior to uploading (i.e., Tuesday morning you’re making claims and choose in the first instance to replace, without realizing you’d forgotten to upload the afternoon prior), it does not mean you’ve lost significant work. You can easily re-load the NARDA’s as involved with each claim in the file that was not uploaded, and add them back into the current day’s work. Not a big deal.

By the way, when talking about uploading those batch files, you’ll note we’re giving you no instructions for the actual upload. It depends on who you’re uploading to. With all, you must log into the website of the entity involved (using the unique login credentials as provided to your company by the entity), then use mechanisms they there provide to accomplish the upload. More specific than that, we can’t tell you. That end of it is entirely out of Rossware’s orbit.

Just because a claim is ultimately provided to a processing entity (whether via direct transmission or via batch upload) — it doesn’t mean the claim is going to be accepted. In fact, you can count on some quantity being rejected, and for a variety of reasons. Thus, even though you’re claiming electronically, it’s critical to assure you’ve implemented procedures and practices to assure notice to yourself of those claims that are rejected, and reaction sufficient to assure the rejection is dealt with and corrected. Success in this aspect alone (at least if you do a significant amount of warranty work) can easily mean the difference between high profitability versus bankrupting loss.

The procedure as needed to bring notice to yourself of rejections will vary by the processor, and you’ll need to seek understanding of same from each such processor.

Regardless, as you’re studying rejections it will become apparent, in some instances, that particular elements of text were not filled into the particular on-screen NARDA boxes as needed to get them into the particular manufacturer’s boxes as needed for a successful claim. When such occurs, you’re going to wonder, which box of the NARDA did that item need to be in, it it to get it into the manufacturer’s box I wanted it to end up in?

In some cases these queries can be difficult to answer. It’s because, in all cases, there are at least two translations taking place:

‍Whenever ServiceDesk transmits a claim or places it into a file, it places claim data into the particular claims-transmission format that’s specified by the selected entity. Each entity has a unique such format. It consists, essentially, of labeled boxes (i.e.,”fields”), that must be formatted according to a very precise set of specifications. With some processors the specification includes a fairly large set of fields; for some it’s smaller. Regardless, ServiceDesk has to pick which boxes from its on-screen NARDA should be placed into which boxes of the processing entity’s specified claims-transmission format. It endeavors to pick as logically as possible, based on prior experience and on the names the entity itself has attached to each such box.

Once the processing entity receives the claim (and in the format as self-specified for the purpose), it (or, rather, its software system) must do a translation on its end. Specifically, if it’s an entity like ServiceBench or ServicePower that has multiple manufacturer clients, each client has their own claim template. The entity must translate from its own claims transmission format into the respective manufacturer’s format (in other words, must decide which boxes from its own transmission format get stuck into which boxes of the manufacturer’s format). In fact, even where it’s a single entity such as Dacor (managing its own claims only, via its own inernally-specified transmission format), a translation is still required. Believe it or not, there is not a one-to-one, item-by-item and within the same-box-titles equivalency between fields in Dacor’s transmission format and boxes in its on-line claim submission/review form.
It’s because of the above translation dynamics that, in some instances, you might find yourself in the conundrum of wondering: what box in Rossware’s NARDA must “X” be in to show up in Box “Y” after the Rossware-assembled claim is handed off?

We have a conundrum too. It’s that we don’t know precisely how any entity makes the translation, from its own transmission format to any particular on-line claim review format. They don’t’ share that with us. They give us specs for their transmission format only.

Given this, our best means of assisting you (for those rare instances where you face this conundrum) is by giving you an easy means to determine precisely what translation is taking place on our end (i.e., from on-screen NARDA to the processing-entity’s claims transmission format). Our thinking is, you can see the names of transmission format boxes we’re sticking stuff into, and logically deduce (or perhaps even by trial and error discover) which one the entity is in fact using for your needed purpose. If that fails, you can contact the entity, and ask them the particular name of the claims transmission box “X” needs to be in. Then, using our translation-exposure utility, you can directly see which of our NARDA boxes fills to that particular claims transmission field.

How does our “translation-exposure” utility work?

Quite simply, when our on-screen NARDA is loaded, a little command bar appears to the left of the NARDA-selection radio button.

When you click on that, you’ll next be asked to pick the processing entity of interest. After you pick it, you get a little message that identifies any claims-transmission format boxes, as exist for that entity, that we’re not sticking anything into at all. More importantly, each of the NARDA’s boxes will become equipped with ToolTips (the little notes that pop up when you float your mouse pointer over) that tell you the precise name, from the underlying entity’s claims-transmission format, of the field contents of that box get stuck into.

Thus, we fully expose the translation that happens on our end. If the need arises, you’ll need to seek help from the processing entity for exposure of what’s happening on theirs. Most typically, though, you’ll find success easier to achieve. We’re explaining these resources because they are ultimately available, if and when needed.

If it’s time to make a warranty claim, it’s very likely also time to make your entry to the SalesJournal. Certainly, you could segregate such entries (and for a whole stack of tickets) into their own separate batch processes, and depending on circumstances that might be the best strategy for you. For most operations, though, we think it’s more likely you’ll find it convenient to tie that entry right in with the claims process.

Your Finished-Forms interface has action buttons arranged in a fashion that makes it easy to integrate (tie-together) a variety of actions (more on this when discussing POS, in the next section). In particular regard to our present discussion, suppose you want each job’s SalesJournal entry tied directly to making its electronic claim.

If you look at the button structure below, you can see there’s a group of actions (violet-colored buttons) that can be included (or not) in the click to enter the Sale:

The specification (as to whether such actions will be included) is based on whether a little checkbox (in each such button’s top-right-corner) is checked. Thus, if you wanted to tie the SalesJournal entry and claims submission directly together, you’d assure that the “Transmit Claim” button has its box checked (precisely as per above), and click on the Execute Sale button to accomplish both.

As a matter of fact, you can pick multiple different saves of any form type as connected with a single underlying ticket number (just append the number, in the form’s own particular invoice number box, with a hyphen then other character, such as 73036-A, for example). If there are such multiples, you’ll be given a list and allowed to pick which to re-load, assuming that such re-load is your preference.