Journal logo

Shane Murphy on Comparing Services Through Real Tasks in Cambridge

A useful comparison starts with what a small team needs to accomplish on an ordinary day.

By Shane MurphyPublished 5 days ago • 3 min read
Shane Murphy on Comparing Services Through Real Tasks in Cambridge
Photo by Jess Bailey on Unsplash

Comparing services can become an exercise in reading increasingly similar descriptions. Every option appears flexible, straightforward and suitable for a growing business. A small company can spend hours discussing those words without learning how its own work would proceed. My preference is to compare services through a handful of actual tasks. The point is not to invent a complicated scoring method. It is to replace general impressions with situations the team can describe, attempt and discuss in practical terms.

Imagine a fictional Cambridge studio choosing a service for arranging customer appointments. Its ordinary work includes offering a first meeting, moving an existing appointment and coordinating two colleagues for one session. These are different tasks, even though all sit beneath the broad heading of scheduling. A service might make the first task easy while making the second confusing. Beginning with the work helps the studio notice that distinction before a polished demonstration creates an overall impression that everything will be equally simple.

The team should choose tasks that represent different pressures. One can be routine, one can involve a change, and one can involve an exception that genuinely occurs in the business. Avoid choosing unusual scenarios merely because they are possible. A useful comparison reflects the company's work rather than somebody's enthusiasm for discovering obscure limitations. I am Shane Ian Murphy, and I think the discipline lies in selecting a few meaningful tests and resisting the temptation to keep adding scenarios until no option can satisfy them.

Each task needs a clear starting point and a visible finish. “Move an appointment” is too open if one person assumes the customer has already agreed and another assumes the service must obtain agreement. A better description says that a customer has requested a different afternoon, the colleague is available and both people need to see the new arrangement. With the situation defined, the team can follow the same route in each service. Differences then become easier to explain without relying on broad reactions.

During the trial, observe where people hesitate. Did they understand what would happen after selecting a button? Could they see whose availability they were changing? Did they have to remember information from another screen? These questions reveal the relationship between the service and the task. Counting every click would produce a tidy number, but the number alone may mislead. Three clear decisions can feel easier than two decisions whose consequences are difficult to understand. The discussion should remain attached to what people needed to accomplish.

I would include the people who will use the service most often, alongside whoever is making the purchase decision. Their perspectives answer different questions. A regular user may recognise a recurring complication immediately; a manager may understand a coming change in the team's work. Neither perspective should automatically cancel the other. The group can distinguish an everyday burden from a limitation that matters only under a particular future arrangement. That distinction supports a more honest choice than declaring one option universally superior.

The comparison should also explore recovery. If somebody chooses the wrong time or invites the wrong colleague, can they understand how to correct the situation? Small teams rarely have spare attention for uncertainty that repeats every week. A service that handles routine work elegantly but makes an ordinary correction mysterious deserves a careful look. This is not a demand for perfection. It is an attempt to understand the amount of thought and coordination the company will have to supply around the service.

At the end, I would write the conclusion in task language: this option supports our usual first appointments well; this other option handles shared sessions more clearly; this limitation requires an extra conversation. Such statements make the decision understandable to someone who missed the trial. They also give the team a sensible basis for revisiting the choice if its work changes. A comparison becomes useful when it shows how an option will fit into a real working day, with its routine actions, ordinary mistakes and necessary compromises.

business

About the Creator

Shane Murphy

Shane Ian Murphy: co-founder/partner, Tri-Party Tokenisation; founder/CEO, Global Secure Technologies (planned 2027 launch); co-founder/partner, Dual Party Capital. Partner, RougeN International Corp. Formerly of Limitless Mobile.

Enjoyed the story? Support the Creator.

Subscribe for free to receive all their stories in your feed.

Subscribe For Free

Reader insights

Comments

There are no comments for this story

Be the first to respond and start the conversation.

Sign in to comment
    Written by Shane Murphy