In February 2003 the vice president who owned the franchisee relationships at Payless Car Rental sent every location a set of conference call notes. Expedia had put mystery shoppers through the rental counters, and the partnership Payless wanted was on hold until the results improved. The notes listed what the shoppers found: a hard sell on collision and liability coverage, agents pushing an upgrade on the grounds that the car you reserved was not safe, empty fuel tanks, and the general condition of the cars.
None of that is a software problem. But there were around ninety franchise locations, each one independently owned, and the corporate office had no way to see what any of them were doing wrong until a customer wrote a letter. Customer service went to the top of the company goals for the next fiscal year. I was on staff at the time, so it came to me.
The first version, and why I rebuilt it
The first version was called the Customer Service Management System. It let the customer service department log a complaint against a location, categorize it, and archive it instead of deleting it. It worked, and it taught me what the real shape of the problem was, which is that I had built it for one of the three parties involved.
I left the payroll at the end of 2004 and kept the account from my own company. The rebuild was the first thing I did on the other side of the table. I started it on the fifteenth of November and had a beta in front of the client by the middle of December. Somewhere in those four weeks it stopped being an internal tool with an internal name and became ClientWire.
A complaint has three people in it
This is what I got wrong the first time and right the second. A rental complaint is never between two parties. There is the customer, the franchisee who ran the counter, and the corporate office that owns the brand and the Expedia relationship. Any one of the three can be the one who has not answered yet, and each of them needs to see something different.
So the ticket does not have a conversation. It has four: corporate to customer, corporate to franchisee, franchisee to customer, franchisee to corporate. Each is its own thread with its own flag on the ticket, and the flags are what the screens actually read. That is why a corporate user can open a list of ninety locations and see, without opening anything, which franchisee is sitting on a complaint.
One form on the website
Everything started at a form in the customer service section of the public site, for renters who had finished their contract and had something to say. The one field I insisted on was the location, because a complaint that cannot be attributed to a counter cannot be answered by anyone. From there the customer never saw the system again; they got an acknowledgment that promised a reply within seventy two hours.
A login for every location
Each location got its own login and its own password. A franchisee saw only their own tickets. Administrators saw every location and every exchange. The three roles are not just permissions: each one gets its own palette and its own navigation, because a franchisee opening this once a week and a corporate agent living in it all day are not the same person and should not be handed the same screen.
Tickets that carry the whole story
Every ticket holds the customer’s original report and shows at a glance who still owes a response. A ticket is open, closed, or escalated, and closing one is a decision somebody makes rather than something that happens by timeout. Closed tickets can always be pulled back and reopened, because a customer who is not satisfied writes again and the second letter should land on the first one.
Whether that was right was not something I could settle on my own, and in March 2007 it got settled for me in about eighteen hours.
I just was informed from [the Atlanta franchisee] that she had open issues in ClientWire that were in the closed category. Here is my concern:
- From time to time [the director] or I may close out an issue by a response from corporate. Neither of us was aware that the franchisee could read our response.
- I may personally close out a file.
- I never understood from the beginning that the location had access to closed records.
Please write the code to only allow corporate management to view closed transactions.
The locations can see the notes placed in the particular record.
Ok, I removed access to closed files by franchisees. Will that accomplish what you’re looking for?
Yes, but they should not see our responses.
Absolutely - thanks
The request as written was to hide closed transactions. That is not what was wrong. What was wrong was that corporate’s internal replies were visible to the location being complained about, which is a permissions question about one conversation, not about a status. The director’s single sentence is what reframed it, and the vice president’s follow-up the next morning is her arriving at the real rule out loud: they should not see our responses.
I shipped a fix six hours after the first message and asked whether it was the right one rather than assuming it was. It was. But the sequence deserves an honest reading: I built it while the two of them were still working out between themselves what they meant, and it happened to land. That is luck sitting on top of one good habit, which is to ask.
The categories came from them, not from me
I did not write the list of complaint types. I asked for it, and I asked in their words: shuttle problems, agent problems, uncleanliness, and so on. It arrived as a list from the department that reads the complaints, and it went into the dropdown as they wrote it. A taxonomy invented by the person building the form is a taxonomy nobody uses.
The seventy two hour promise
The acknowledgment told the customer they would hear back within seventy two hours, which meant the software had to know when that ran out. An escalated ticket with all four conversations still empty after three days gets reclassified and sends an alert.
The host had no scheduler, so there was nothing to run that check on a timer. What it does instead is check on the way in: the sweep runs at the top of the login page, so the clock is enforced by the next person who opens the system. It is not the design I would draw on a whiteboard. It is the one that worked on the hosting we had, and it never missed, because somebody logs in every morning.
Reporting for the corporate office
Corporate wanted one screen that answered one question: what needs attention right now. Open issues, by location, exportable, and saveable so the same report could be run again next month against new data. By the spring of 2007 the system held over nineteen thousand tickets and fifty thousand pieces of correspondence across ninety one locations, and the shape of that traffic is the part I am proudest of: the overwhelming majority of it is a franchisee talking directly to a customer. Corporate chasing a franchisee is a rounding error. That was the argument for building it.
A field that would not let Canada complain
In January 2009 a phone sales rep at the reservation partner wrote up something he had hit on the customer care form.
He rented a car in Toronto and wanted to file a complaint with customer service through the following link. He is a resident of Canada and of course they use Postal Codes instead of Zip Codes and the web site would not allow for the use of Postal Codes. I advised him to use the Zip Code 33714 so that his complaint would process.
I do not know the purpose of the “Zip Code” field, but as a customer I would find if quite frustrating if I could not send a complaint to customer service via this option, leaving only a toll number to call. I just thought that someone might want to know about this.
I agree with the phone sales rep - lets remove zip code
No prob, zip removed!
A required field with a United States shape had made it impossible for a Canadian customer to complain about a Canadian rental. The workaround, invented on a phone call by a man who did not build the form, was to tell the customer to type a Florida zip code so the page would let him through. Somebody had to coach a customer to lie to a form in order to complain about the company.
The field cost nothing to remove and it was gone a hundred minutes after the vice president agreed. What I keep is not the fix. It is that the person who found it had no route to report it except writing to somebody who knew somebody, and that he argued it as a design question rather than a bug: he did not know what the field was for, and he could see what it was doing.
The ticket it did not catch
In January 2007 the vice president forwarded me an escalated billing dispute from a rental at a Phoenix location the previous autumn, and asked me to find it in ClientWire. It was not there. I searched the database by hand and found nothing.
The customer had written to Payless more than once by then, so there was no question of them not trying. They had simply not arrived through the form. Every intake path I had built assumed the customer would find the one door I designed, and the ones who wrote a letter, or called, or replied to an old email, fell outside the system entirely. A complaint desk that only records complaints filed correctly is measuring its own form, not its customers.
What it carried forward
ClientWire ran for six or seven years, well past my last invoice, until a much larger rental company bought Payless and moved everything onto its own system.
The four-way conversation is the piece I still use. Twenty years later I directed AI to build a support desk for a wheel business where every ticket hangs off the order it is about, so anyone picking up a thread sees the whole history instead of a subject line. Different industry, same discovery: the ticket is not a message, it is a record of who owes whom an answer.