With eSignature rolling into larger beta it was time to address some flexibility concerns that had come up at our second pilot store.

 

Their chief problem was that when they took a signature on a Hard Copy they wanted the software to automatically print two copies at two different printers - one at the Service Counter (for the customer to take home) and one at the back counter (for the technicians). With our first version of eSignature this was awkward because the user was given one prompting screen and would need to use the "print" dialog twice - pretty difficult in a fast paced retail environment.

 

So... while we were out at our annual dealer conference last week I bounced this idea around with a couple service managers. We came up with the idea of "Document Actions". The idea is that eSignature already managed the layout of the document, it's not that big a stretch to allow it to also manage WHAT we do with the document once we have it. If we allow our document management infrastructure to take care of this we can specify that this document should be printed on Printer A, then printed on Printer B, and finally reviewed with Printer C. The flexibility can all be managed in our Document Layout interface and tailored to the dealerships processes.

Finally it's worth noting that all this new Document Management is only kicked off if you "Enable Document Management" for that specific document type. Once that checkbox is enabled the background, signature capture, and printing is all handled by eSignature - the existing printing control in Service is totally ignored.

Just overcome an extremely challenging problem we've been having. Our COM application was calling out to a dot net assembly through COM Interop and when the dot net assembly returned a response the process would get terminated... no friendly output, error messages, or log entries - just dead.

The solution was to totally REMOVE the Dot Net 2.0 framework and re-install. We tried a REPAIR first but that didn't seem to do anything.

It's worth mentioning that the problem didn't occur when calling into the dot net assembly but rather when it returned something to VB6... very strange.

Anyway, strike another issue off the project wall. Time to move back on to Prospecting!

Addendum> Apparently this issue is caused by one of the Dot Net 2.0 Security Updates from Windows Update! For now we're avoiding this patch.

Yesterday we installed Aristo Vehicle Managment into Alpha at a dealership here in Calgary. We'll be working with them over the next few weeks to iron out any wrinkles as we continue to push forward on our Aristo Front End project. Couple highlights...

A true common vehicle file (which provides for some extremely powerful and concise search capabilities)...

The tree in the top-right corner allows searching by vehicle type according to Make, Model, and Trim level. This search is hierarchical so you can search for any type of unit. We also support search for specific unit types, options, pricing, or even across vehicles that have been sold to customers for potential lease returns.

 

We've also completed an integrated vehicle screen accessible from all modules. This screen allows all departments to have the same view of a vehicle complete with all vehicle history.

This common UI means that given the right security a user can review and edit any information of a vehicle by selecting the correct View in the top right hand corner. Vehicle history is reported down the right side of the screen and allows immediate access to any "event" (such as a Repair Order or Sales Rep Hold) which has affected this unit.

 

This project will be the foundation for our further work on Front End and provides a major step forward on the Aristo Front End project.

Our Front End Aristo project is going to be managed by what we call a Product Team. A Product Team is basically three individuals who will make it their top priority to achieve deployment of the Aristo Front End application. Each of these individuals has an inherent goal for the project and by working together as a team will come to a consensus on these goals. The Team is made up of the following...

Strategic Product Manager (Dave)

The Strategic Product Manager is responsible for understanding what the market demands of the product. It is their responsibility to understand business cases, market requirements, as well as scheduling demands.

Technical Product Manager (Chris)

The Technical Product Manager works to understand what can be built in what amount of time to satisfy the market demands. Their responsibility is to help estimate project timelines and to ensure project milestones are accomplished.

Sales Product Manager (Pat C)

The Sales Product Manager focuses on understanding how the product will be received by the market. Their responsibility is to be THE product expert, to act as a sales and installation resource, and to create excitement around the product.

 

Starting asap we're going to convene the Product Team daily for 1 hour - no longer - to discuss the finer requirements for this project. Based on these meetings we will create a project schedule defining which features will be implemented in which iteration. Our schedule will be have five 1-week iterations with our Front End module ready for install by the end of our final iteration.

It's an exciting time for this project; by having three resources each focusing on their specific "needs" for this project we should have faster completion, more complete requirements, and a more exciting product release.

After a couple weeks in alpha we're now moving our Service eSignature product into Beta. This project integrates with our service module to electronically sign and store vehicle repair documents. At the right store this allows a service department to dramatically decrease wear and tear on their printers as well as paper consumption.

The system itself is pretty simple to use. Once we've enabled eSignature on a dealers system we enable two more buttons on the Open Order and Order Summary screens. These buttons allow you to take a signature and to display documents associated with a Repair Order.

When the CSR gets a customer to sign off on work (say when writing up the Service Order and printing a Hard Copy) they are shown an electronic copy of the document on their monitor along with a signature window. The CSR shows the work being authorized to the customer and they use the device to "sign" the document.

At this point that document is attached to the corresponding Repair Order. Any time that Repair Order is reviewed the user can press the Documents button to see a list of documents.

Double-clicking any of these items will display the full document and it can either be emailed to the customer or simply printed in the service department.

 

 

Technically - our system is based on some fairly simple usb signature capture pads from a company called Topaz Systems - http://www.topazsystems.com/ - we use a wrapper around the Windows RDP Client to allow these client-side USB devices to be used by our server-side apps.

On top of that we need an extremely robust document management infrastructure. It's important to understand that these documents must be stored intact WITH the customer signature - it's illegal to store the signature independant of the document.

All this aside, this application works well. We still expect some changes from our additional Beta sites but it's an exciting project that has some immediate impact for our clients.

We're spending the next two days and the remainder of our trip in London. We arrived two nights ago via Heathrow and took the rail direct to our hotel; it's amazing how effecient and effective the entire rail system is. We managed to get from the airport to the door of our hotel with 2 trains (Heathrow Express and the Tube) in about 25 minutes.

We're staying in Notting Hill, which is west of downtown, and north of Hyde park. Our first day we did the bus tour, went to the Tower of London, and the London Eye - a gigantic ferris wheel as part of the exhibition on the south side of the river.

At night we went on a walking tour with some old pubs and ghost stories.

Today we went to the National History Museum / Science Museum (waaaaay too may kids!), then the Imperial War Museum, and Parliament/Big Ben/Westminster Abbey.

Vacation is starting to blur just a little - might be time to come home. See you soon.

Words we've made up...

- blung: to have had bling and to have lost it.
- snickles: a magic candy which is a combination of Snickers and Skittles.
- azine: Andrea pulled this out of the dictionary to cheat her way into finishing Scrabble (she still came in dead last though)

Beers we've had (that we remember)...
- Affligem
- Leffe Brune
- Chimay Blue
- Tennents
- Belhaven
- Caledonian 70
- Caledonian 80
- Scrumpy Jacks Cider
- Staropramen
- Kronenberg Blanc
- Sherlock Holmes
- Olde Speckled Hen
- Badger

We've spent the last two days in Edinburgh. It's been reasonably rainy but we did get out to see a few sights.

We've spend the last 3 days in north-east Scotland with relatives - Ellen and Henry Bruce. They have a beautiful house about near a small town called Turriff which we toured out from each day.

Yesterday was our "bonus" day. The idea was that we were going to take our rented Renault Twingo, and visit as many countries as possible. First you have to meet the Twingo... golfcart that goes 140 km/h... It took us two days to figure out how to put it in reverse.