Process /

Beam Services, Warranty, and Support Initiative

My management of a new potential revenue stream

So what is this? Well ... Here's some background!

President Obama is speaking to a woman on a Beam.

Beams are devices that deliver an audio and video experience like Skype or Facetime, along with mobility.

They provide unique and valuable long-distance accessibility.

But here's the issue:

Beams are like cell phones…they are complicated pieces of hardware that require a connection to a dedicated network.

And in addition … like any consumer electronic device… they might require calls to support specialists, and (rarely) even need serviced.

So when Beams debuted in 2011 (before my time), paid service plans and warranties were certainly DISCUSSED … but never really levied. Better to build market share.

"It was like getting a cell phone plan for free!"

But a few years later it was time to tap that important source of recurring revenue, and it came to me to work this all out.

Stakeholder Research

I met with all the stakeholders over several weeks, multiple times. Senior VP, VP Operations, Head of Sales, Head of Software, Operations Manager, and a half dozen brilliant software engineers

And it couldn't be LESS straightforward

Competing notions, flawed assumptions, differing strategies? It was all there.

There was one thing everyone agreed on ... we couldn't manage this with SalesForce or similar. Our directive is clear ... WE must own the database.

Considerations (here are a select few...)

• How do we introduce a recurring service fee model to customers who are accustomed to “Free Beam”?

• Are there legal issues?

• Where does this fit into or replace existing methodologies or tools?

• How will this change the Customer Success (Support) workflow?

• What will the customer experience be? How about the Administrator experience?

• How did we manage this before? And how will that change now?

• Can we outsource this? Or use something off-the-shelf?​ (i.e. has someone ELSE figured this out already?)

• Can we keep everything secure?

These are just some of the questions that needed answering. Later we’d add other pressing questions like:

How will this affect our future relationships with distributors and resellers?

EXPLORATION:

With pages of notes, I spent a few weeks sorting and playing, looking for an in-road.

We can't use Salesforce for a final solution, but we still have to integrate the part we use NOW with whatever we build. And these must integrate with our ERP database.

Internal sales process

+

Amazon

+

Stripe

+

Other Resellers

The developers say auto-renew is a problem. But that should be part of the spec.

How will this affect our future relationships with distributors and resellers?

Beams must always be sold with service plans from now on

Need to flow out the entire life of a Beam, from creation, certification, sale, linking, service/warranty initiation, right through to potential upgrades and eventual decommissioning

Speaking of upgrades, these must be integrated as well. Also, do we offer downgrades? Refunds?

Definition:

Time to create some documents. We started with a Requirements document that outlined everything we wanted this structure to do.

NOTE: In an effort to be mindful of intellectual property, I am only showing snippets of documents

Based on that collectively-created Req doc, I started breaking things down. Since we added partners in the form of distributors and resellers, we decided this initiative should take the eventual form of a "portal". A collective place where Users, Admins, Partners and Beam Owners. Parts of the portal would be built-in to our current management software, but the main portion would exist on it's own.

A definition of features

And now let's get more granular

I created two important things: One, a list of User Personas likely to use the site, and two, an extensive list of events dictated by our assumed features

And once I had these lists, I could combine them into full-fledged User Stories.
From here I could begin wireframing/flowing.

FLow/Wireframes:

This flow document endeavored to show three things:,
- the user-facing experience,
- the software touchpoints, and
- Jira tickets associated with each story/task.