On May 5, 2002, two days after my last day at the school district, I left Wisconsin for Florida. Payless Car Rental had hired me for web work. I was nineteen, and I had a fairly strong opinion about how a company’s website should work. One of the first things they handed me was the website itself.
This is what they handed me. It is not in my files, because nothing in my files predates me: the Internet Archive caught it on April 18, 2002, seventeen days before I left Wisconsin. It runs to 1,225 pages of hand-written HTML and three ASP files, and the three are not the booking engine. The reservation button did not belong to the site at all. It handed you to another company’s server.
One website, then seventy
The redesign was the visible part. Behind it the work multiplied. Around seventy rental locations got their own small site, each with its own hand-written city description. The franchisees got an intranet, and I rebuilt it three times in two years, under three names across three brands. Marketing offered me a position, and I took it.
Those location sites were called iCENTRALs, and the booking form on them was not mine. The reservation engine belonged to the vendor who ran reservations, and it arrived as a component I dropped onto my page. So a visitor who had already told us where they were, by opening paylessdenver.com, still met a form with no city in it.
What would it take […] to ensure that the quick quote on an iCENTRAL page default was set to the iCENTRAL location?
Example
Paylessdenver.com
Icentral default - select city DENVER
These iCENTRALs are going to kill me. First the default needs to be set at the location value of the iCENTRAL and how can one book when there is no submit.
In the meantime, I’ll fix the submit button. However, the Quick Quote doesn’t allow us to specify a specific location. It’s something REZlink would have to build into the quick quote.
During our discovery we talked about making the Quick Quote specific to the destination. In other words, we wanted the quick quote to display the current city of the current destination. At this time, this is not possible.
There are two defects in that November sentence and I could only fix one of them. The missing submit button was mine, and it was gone by the end of the evening. The city default sat inside somebody else’s component, and the only answer I had was that I could not do it, which is a much worse answer the second time you give it. The following April marketing asked what the alternatives were, and the question finally went to the vendor’s own engineers instead of to me. There is no message in the archive that tells me it ever got built.
I would handle that differently now. I kept answering the question I had been asked, which was whether I could make the change. The useful question was who owns the Quick Quote sitting in the middle of my page, and how do I get onto their list. It took me two years to escalate something I had already proved I could not fix.
Then the brands multiplied
Payless was not one company. It was a family of them: car rental, car sales, parking, lodging, franchising, the loyalty program. Each one wanted its own site and its own look, and each one had to still read as Payless.
Seven of those sites are still running, including the holding company and the signage program. Open one and use it, then move between them with the tabs.
That is where two years of graphic design school earned their keep. I designed campaign creative for Payless, including the Just Drive campaign. I also designed the masthead system the taglines sat in: one fixed slot opposite the logo, “just drive” on Car Rental, “just park it” on Parking. The annual print program was mine: the campaign posters, the rental jackets and the global location directory. So were the hang tags, the airport signs and the livery on the shuttle buses. The same art went into the interactive Flash ads I built for the web and animated by hand, frame by frame.
The complaint that had three people in it
A rental complaint is never between two people. There is the customer, the franchisee who runs the counter, and the corporate office that owns the brand. Any one of them can be the one who has not answered yet.
Payless asked me for a way to see that. I built ClientWire: one form on the website, one ticket per complaint, and a screen where the corporate office could see at a glance which franchisee was sitting on one. Most of the traffic turned out to be franchisees talking directly to customers, which was the whole argument for building it. It has its own case study.
The other side of the table
By the end of 2004 I had hired and trained my own replacement, moved home to Wisconsin, and kept the account from there: the same work, billed through my own company, for five more years. I had left the staff job as Web Development Supervisor.
That is when the work turned into a product. Over five weeks that winter Payless bought three more pieces of the publishing tool on three separate contracts, and what I kept at the end of it was a product rather than three features.
The week I argued my way out of the automation
The first of those three pieces let the franchisees request their own promotions. As designed it was fully automatic: a franchisee picked the dates, and the software worked out which special ran where, and when. Four days in December 2004 changed that, and I was the one who asked for the change.
Because there are so many variables in choosing the specials (i.e. holiday/seasonal specials, overlapping specials [how should the system determine who gets placed where/when], expiration, renewal, etc.), I think it would me much easier for the web team to be involved at all times to determine these factors. It seems that the system will need a “human touch” in order to function like we want it to.
I am fine with your recommendations please proceed as you deem best.
In order for the specials to be automatically placed on PCR.com, I’ll need to program the current specials page to accept this. Unfortunately, this was one of the other projects originally on the roster - titled PCR.com Specials Enhancement.
I’m sorry to drop this on you at near the last minute, but I just didn’t realize that the two projects went hand and hand.
In a few months, we can develop a “plugin” to convert the tool back to the original plan. This would include all the autonomous functions originally designed. (This plug-in would fall under the Specials Enhancement project, so besides the project cost, Payless would incur no extra costs)
To update program the iCentral Administrator as it needs to be, what would the total cost be at this time? I believe I would rather have a complete project then one in phases.
As it is right now, the only extra cost would be 800 dollars for the Special Page enhancement. That would complete the project.
Go ahead and do it.
Two things in there have held up. The first is that I talked a client out of the more impressive version of their own tool, in writing, just before one in the morning, because the scheduling logic was beating me and I said so rather than shipping something that guessed. The second is what happened when I found the dependency I had missed: I offered to split the work and bill the second half later, and she turned the phasing down and asked for the whole thing. Eight hundred dollars, approved in under two hours.
Half of that is a lesson about scoping. The other half is that a client who trusts you will often spend more than you were about to ask for.
The point of all of it was that nobody had to wait for me. They opened the page, changed what needed changing, saved, and it was live. No ticket, no email to the web guy.
By the end of 2006 the tool had a name, Imagine, and it was running the rebuilt corporate site. The launch note I sent that December says what it was for better than I could now: she can make changes as often as she requires, and will not need me to upload them for her. Marketing ran their own promotions from it too, picking the winners and pulling the entries themselves. Imagine has its own case study as well, because it outlived Payless by years.
A report they asked for, and an answer they did not expect
In October 2007 a one paragraph brief came down from the vice president.
We need to consider placing a means in which consumers can share their experience on our site vs. on sites we do not control. Please provide me with a report next Monday as to the positive and negatives of adding an application to our site. I also want a current list of the sites that consumers can go to get advice on products and services.
A car rental company asking in 2007 whether to put customer reviews on its own website is really asking whether it is prepared to publish its own bad news. I had the evidence to answer that, because I had built the complaint desk and I read what came through it.
The report I sent back a week later spent most of its length arguing for doing it, and then recommended against it. Not because the reviews would be bad, but because the company was not ready to be told in public what it already knew in private.
As a company, we must decide whether we are “good enough” to open up to the public this way. Whether we like it or not, people will review us - whether it’s on our own site or not. They will complain, compliment, and spread their word. By opening our website to this type of reviewing process, it is showing that we’re confident in our operation, and that we think people are, and will be, happy with our service.
What I actually wrote was that plan B was a step toward plan A rather than a substitute for it: expand the form, learn where the service was weak, fix it, and then open the doors. The framing I used for the private version was an expanded mystery shopper, except that we would know who the shopper was.
Seven weeks later the question came back from a different direction, buried in a marketing thread about a booking partner. I did not build it then either. I re-sent the October report with four sentences on top of it.
I wrote the following long-winded email back in October about adding a ‘reviews’ section to our site. While it’s no problem to implement on our website, I think we should think about some of the things I mentioned before we open ourselves up to it. Let me know if you still want to proceed, and I’ll have a mockup and a write-up on how it would work to you by 1pm.
That part I would still defend. The build was never the hard part, and saying so out loud removed the only argument that mattered to the person asking. What was left was the actual question, which was whether the company wanted to hear the answer in public. I do not have a message in the archive that tells me which way they finally went.
The one I never redesigned
Payless Perks was the loyalty program, and you joined it through a form on our site. Between June 2007 and May 2008 that form failed in at least six different ways, and I have a message for every one of them, because they all came in through the complaint desk I had built.
Why doesn’t your Payless Perks new sign up/sign in function work?????? I am very upset that I filled in personal information including my drivers license number and registered and did not receive any email confirming my registration, an email sending me discount, etc., as was promised.
Is you online signup for Payless Perks not working??? When you click “finish registration” you get a page cannot be displayed error.
I just rented a car through Payless for the first time and tried to sign up for a Perks membership. There seems to be some kind of problem with the website. I rec’d an email with a link that won’t work.
Perks program signup, shows an error on select. cannot sign up.
I went to sign up and it informed me that my email was already in the date base. I then petitioned for my password. The system sent me the word “null” as my password, it don’t work.
It looks like with all new Perks accounts created AFTER the new release, the password is not being saved. When they try to have the password sent to them, it comes back as “null” because the password wasn’t saved. This is an urgent problem as all new Perks signups are unable to use their account without our intervention.
Every one of those was answered. Every one was forwarded, diagnosed, fixed and closed, usually within a day. Not one of them was ever treated as evidence about the form itself.
Perks belonged to the reservation vendor too, the same as the booking widget on the iCENTRALs. So the reflex on both sides was to file each report as a defect in somebody else’s code and move on. What nobody did, me included, was put the eleven months on one page and notice that the shape never changed: a customer hands over a driver’s license number, the form accepts it, and then the flow goes quiet or dies at the last step. The failures were different every time. The experience of the failure was identical every time.
That is the counter-example to the two sections above. Same company, same year, same inbox, same person reading it. The complaints about the counter staff turned into a system, and the question about reviews turned into a written argument. The complaints about our own signup form turned into a bug queue, and a bug queue is what you build when you have decided in advance that the design is not the problem.
Where it went
The design changed several times over those years. ClientWire ran for six or seven years, well past my last invoice. Not long after, a much larger rental company bought Payless and moved everything onto its own system.
I had come for a web job. By the time the account ended I had built the sites, the intranet and the complaint desk, and designed the annual print program.
From the archive
I kept these: the sub-brand sites, a couple of the comps, and one of the Flash ads.
And the front page across the whole run. Twelve captures from 1999 to 2009: the four before me, then every redesign on my watch, ending where I left it.
