When you need a web service, not another spreadsheet

Almost every working process starts with a spreadsheet, and rightly so. A spreadsheet takes five minutes to create, any colleague understands it, and it needs no agreement with a contractor. For the first few dozen records it beats any system.

The trouble is that the moment a spreadsheet stops coping never arrives all at once. It keeps working — there are simply more and more manual agreements around it: don’t touch column K, only Olya changes the status, the current version is the one in Tuesday’s email.

Signs the process has grown

There are a few symptoms that show a process has outgrown a file. Individually each is bearable; together they mean the spreadsheet is kept working by people rather than by itself.

• the spreadsheet has acquired rules that are written down nowhere
• the history of changes is reconstructed from correspondence
• some of the data must not be seen by everyone who can open the file
• outside participants — clients, partners — are not let in, and are written to by hand
• copies have appeared “just in case”, and nobody knows which is the real one

Roles and access

The main thing a spreadsheet cannot do is show different people different things. In a file, access is granted to the whole sheet: either a person sees everything or nothing. As soon as a client, a contractor or an intern enters the process, that becomes a problem.

A web service begins with exactly that question: who signs in, what they see, what they may change. Roles are described before the interface, because the whole structure depends on them: which screens are needed, which actions are available, what happens when someone tries to do more than they should.

There are usually more roles than anyone names at first. Besides the client and the manager there is almost always someone else: an accountant who needs only the documents; a director who needs a summary and nothing more; a contractor let into one specific request. Each such role is not a separate product but a handful of access rules — and it is better to design them in from the start.

The client portal

A portal usually pays for itself not through features but through work it removes. A client who can see the status of their request does not write to ask “how are we doing”. A client whose documents live in one place does not ask for them to be sent again.

So the first portal is usually minimal: requests, statuses, documents, a history of actions. Everything else — notifications, comments, nested approvals — is added later, once it is clear what people actually miss.

Status names deserve separate thought. The client sees them without context, and “in processing” tells them nothing while “waiting for your documents” tells them everything. A good status describes what is happening and whose turn it is. That costs less than any feature and removes more questions than notifications do.

The admin area

The admin area is remembered last, and that regularly turns out to be a mistake. If the team has no interface to correct a status, undo an action or see what happened, every unusual situation turns into a request to a developer.

A minimal admin area means being able to find a record, see its history and change what may be changed by hand. It is needed from day one, because unusual situations start immediately.

The action history matters more here than it seems. When a client insists they sent the document and the manager insists they never got it, the argument is settled in ten seconds if you can see who did what and when. Without the history it is settled by a raised-voice conversation and somebody giving in.

The service MVP

Moving from a spreadsheet to a service does not have to be a wholesale migration. It is more sensible to pick one scenario — the one with the most manual follow-ups — and do it properly: with roles, statuses, history and an admin area.

The rest can quietly stay in the spreadsheet for a while. That is fine: a service and a file can coexist until the service proves it is the more convenient place. The reverse order — migrate everything first, work it out later — costs more and more often ends with everyone back in the spreadsheet.

The move has a cost worth stating plainly. A spreadsheet can be edited by anyone at any time; a service only where that was designed for. For the first while this irritates: the familiar “just fix the cell” suddenly needs a dedicated button that does not exist yet. So the first list of improvements is collected not six months later but two weeks after launch, while the irritation is fresh and specific.

One more question better settled before launch is what to do with the old records. Migrating everything is usually unnecessary: the active requests move over, the archive stays where it was and opens by link. That saves weeks of work and gets in nobody’s way, because people look into an archive rarely and for a specific reason.