Jive Communications · 2015
Making Jive Easy to Do Business With
Channel partners — about a third of the company's business — were choosing competitors like RingCentral and 8x8. The reason kept coming up: "Jive is a great company, but it is just too hard to do business with."
30-second read
What matters in this case
- The challenge
- Channel partners were choosing competitors because Jive was too difficult to do business with; executives asked for onboarding automation.
- My contribution
- I reframed the brief around the desired outcome, assembled a cross-functional team, and created the company’s first service blueprint.
- The result
- The team delivered coordinated software and process changes that materially improved the partner experience.
- Pivotal decision
- We solved the end-to-end service problem instead of automating one broken step, even though that meant challenging the original brief.
- 1st
- Company-wide service blueprint
- 8 functions
- Represented in one temporary journey team
Challenging the Brief
Leadership asked us to automate onboarding. Jay (Product Manager), our dev team, and I first asked what business outcome automation was supposed to create.
Channel loss — not manual work — was the risk. After doing frontline jobs and taking about six customers through the complete flow, we found failures across sales promises, provisioning, support, and billing. We changed the unit of design from one workflow to the whole service.
Understanding the Problem Firsthand
We didn't design from conference rooms. We trained on frontline jobs, ran real customers through onboarding, and listened to the people doing the work.
- Learned the jobs ourselves Frontline staff trained us to do their work — we didn't just observe the process, we experienced it
- Ran real onboardings Put ~6 customers through the full onboarding process end-to-end, experiencing every pain point firsthand
- Interviewed everyone Customers, resellers, and employees involved with onboarding — understanding the full picture from every angle
Key Realization
"Seems like the left-hand doesn't always know what the right hand is doing." That wasn't just a process problem — it was an organizational one. No one had ever mapped the full customer journey across departments.
Building the Team That Could See the Whole Service
No department owned onboarding end to end. We asked leadership to let one person from each of the eight functions temporarily step away from their usual team and form one integrated service team.
Together, they mapped the journey, ran experiments, and designed improvements across departmental boundaries. Each person knew their own queue; working side by side exposed where context disappeared, tasks were duplicated, and customers were delayed. We gave the group shared evidence, a daily standup, and one map so they could resolve those contradictions before they reached a customer.
Temporary operating model
Everyone working on the journey saw the same evidence.
Journey owners
Delivery sequence
- Sales Promise
- Onboarding Setup
- Provisioning + hardware Ordering · shipping · provisioning support
- Support Recovery
- Billing Payment
We kept the work visible. Everyone posted findings to a private learning journal as they surfaced, so leaders could follow the evidence without waiting for a readout. In daily standups, Jay and I prioritized the next questions; then I facilitated the group through every touchpoint, dependency, and ownership transfer.
The Service Blueprint
2015 cross-functional blueprint
No one owned the journey end to end.
Across five stages, the blueprint connected customer actions to frontstage interactions, backstage work, systems, and policy — making failures at the transfers visible.
- 5
- journey stages
- 4
- operating layers
Scroll or swipe to follow all five stages
| Onboarding journey Customer → operations | 01 Buy Sales Sales → Onboarding | 02 Submit Onboarding Onboarding → Provisioning | 03 Provision Provisioning Provisioning → Hardware | 04 Activate Support Support ↔ Onboarding | 05 Pay Billing |
|---|---|---|---|---|---|
| Customer actionWhat people do | Compare and commit Agree on scope, price, and timing. | Submit setup details Find a CSR and provide account records. | Wait for service Confirm numbers, delivery, and go-live. | Test and get help Diagnose problems when activation stalls. | Understand and pay Reconcile charges and keep service active. |
| FrontstageWhat people see | Quote and sales promise An “easy switch” sets the expectation. | Forms + follow-up Several teams ask for similar information. | Updates + hardware Devices and instructions arrive from different owners. | Calls + ticket updates Customers repeat the story across channels. | Two manual payments Hardware and service arrive on separate bills. |
| Line of visibility | Frontstage Visible to customer Backstage Not visible to customer | ||||
| BackstagePeople + handoffs | Relay requirements Notes move forward without shared readiness criteria. | Validate and re-enter Missing context sends teams back to the customer. | Coordinate the sequence Porting, inventory, and shipping move through queues. | Reconstruct history Support searches sales, onboarding, and ticket notes. | Reconcile accounts Billing and support recover missed payments. |
| Systems + policyWhat shapes the work | CRM + quoting Optimized for closing, not delivery. | Forms + email Separate tools trigger separate conversations. | Carrier + inventory Each tool tracks a task, not the journey. | Phone + ticketing The history exists, but not as one narrative. | Split ledgers + policy Rules block cards and one-click autopay. |
| Failure signalsHover or select for context |
|
|
|
|
|
The sales promise described a fast, simple, seamless switch. After signature, delivery teams requested a customer service record, port dates and numbers, and device addresses.
Failure signal · Misaligned expectations
The promise arrived before readiness
- Customer experience
- Partners heard “easy switch,” then discovered porting, hardware, and timing requirements after committing.
- Internal effort
- Sales notes did not carry a shared definition of readiness into onboarding.
- Design response
- Shared readiness criteria aligned the promise with what delivery teams could support.
At 9:04 AM onboarding requested the customer service record. At 11:18 AM provisioning requested the current carrier record. At 2:41 PM hardware requested the same shipping addresses.
Failure signal · Email spam
The same setup data was requested again
- Customer experience
- Customers received separate requests for their CSR, account records, and shipping details.
- Internal effort
- Onboarding and provisioning validated the same information in separate tools.
- Design response
- We consolidated lifecycle messages and moved setup into one guided flow.
Requirements moved from onboarding to a provisioning porting queue, then to a hardware shipping queue. Each transfer required the next team to reconstruct status.
Failure signal · Wasted handoffs
Progress depended on queue-to-queue transfers
- Customer experience
- Customers waited while porting, hardware, and activation moved between owners.
- Internal effort
- Each transfer required another person to reconstruct status and dependencies.
- Design response
- Broader ownership and coordinated hardware timing reduced the number of transfers.
The activation problem appeared as a phone explanation, a twelve-reply email thread holding shipping history, and a support ticket with no linked sales context.
Failure signal · Context lost
Customers became the integration layer
- Customer experience
- When activation stalled, customers repeated the same story by phone, email, and ticket.
- Internal effort
- Support searched sales, onboarding, and ticket notes to rebuild one history.
- Design response
- Shared context and cleaner handoffs preserved the customer narrative.
A 199 dollar hardware invoice was due March 12 under a hardware account, while a 252 dollar and 47 cent service invoice was due March 25 under a separate service account.
Failure signal · Split billing
One service arrived as two bills
- Customer experience
- Hardware and service charges arrived separately, forcing customers to reconcile one journey across two balances.
- Internal effort
- Billing and support traced accounts manually when payments did not align.
- Design response
- The unified invoice created one accountable balance.
The payment screen showed bank transfer as available while credit card and automatic payment were disabled.
Failure signal · No credit cards
Payment policy blocked the familiar path
- Customer experience
- Customers could not use cards or enroll in one-click autopay.
- Internal effort
- Billing absorbed manual payment questions and exceptions.
- Design response
- The new portal added card and ACH payments with autopay.
Two balances were invoiced, the due date passed without automatic payment, and service became at risk before support recovered the payment.
Failure signal · Forgotten payments
Manual payment created avoidable service risk
- Customer experience
- Separate due dates and no automatic payment made missed balances easy.
- Internal effort
- Support and billing recovered overdue balances after the fact.
- Design response
- One balance, clearer reminders, and autopay reduced the recovery loop.
Synthesis
Seven signals revealed three systemic patterns.
The individual defects were symptoms. The deeper problems lived between teams, channels, and billing systems.
-
Promise and delivery were disconnected
Sales sold an easy switch, but readiness criteria and account context did not travel into onboarding.
-
The customer carried the context
Disconnected email, phone, and ticket histories forced customers to repeat details and chase status.
-
Payment policy created service risk
Split bills and no card or autopay option caused missed payments, interruptions, and avoidable support work.
What We Shipped
The blueprint separated interface problems from process and policy problems. We shipped the highest-leverage changes in both.
Pryde Enterprises
Invoice #123111
OpenService period Jan 25 – Feb 25, 2017
- Balance due
- $381.95 One combined balance
- Due date
- Mar 25, 2017 26 days remaining
- Payment method
- AMEX Ending in 4941 Autopay available
| Description | Quantity | Rate | Total |
|---|---|---|---|
| Business voice plan15 SIP trunks | 15 | $19.95 | $299.25 |
| Direct phone numbersService charge | 4 | $4.75 | $19.00 |
| Included minutes15,965.60 minutes | — | $0.00 | $0.00 |
| Toll-free usageMetered charges | 2 | $0.02 | $0.04 |
| Regulatory recovery feesState, local, and federal | 1 | — | $63.66 |
Step 3 of 4
Verify your carrier details
We’ll use this information to move your phone numbers without interrupting service.
- ✓Account
- ✓Numbers
- 3CSR details
- 4Review
After the Team Disbanded
When the cross-functional team dissolved, I kept going. I listened to sales calls, support calls, voicemails. Read through ticket histories. Mapped touchpoints in chronological order until there were no surprises left.
The deeper I went, the more I found: games of phone tag between customers and support. PCI compliance gaps in how sales reps collected billing info. Competitors intentionally slowing offboarding to raise switching costs.
The Transformation
From "too hard to do business with" to "Channel Partners love selling us"
Commercial
Partner language shifted from “too hard to do business with” to “love selling us,” helping Jive compete for larger deals.
Effort + experience
Removing redundant steps, transfers, and messages reduced effort for customers and employees. The remaining touchpoints became clearer, more consistent, and easier to use.
Organization
Support, onboarding, and billing teams adopted customer-centered practices that outlived the project.
What I Learned
The blueprint’s value was not the diagram. It made ownership gaps and downstream effects discussable while the team could still change them.
I learned to treat policy, team boundaries, and product UI as one design surface — then choose the right intervention for each failure instead of forcing every problem into software.