Tag business

Implementing a digital worker isn’t just a tech deployment, it’s a people, process, and product orchestration.

Jourdan Hathaway Leave a comment

We are implementing a digital worker in our contact center named GAbby (yes, clever).

Implementing a digital worker isn’t just a tech deployment, it’s a people, process, and product orchestration. I’m going to build out loud here and share real life reflections from our current implementation (given that General Assembly trains on AI, it only makes sense that we too have it embedded in our own workflows.)

When we implemented “GAbby,” our AI digital worker in our Admissions Contact Center, the pilot was laser-focused on measurable outcomes: throughput, transfer rates, incremental enrollments, and cost savings. We didn’t treat it as a tech experiment—we treated it as a business experiment.

At the surface, implementing an AI-powered agent like GAbby might seem straightforward: feed it some data, map out a call script, and launch. But the reality is far more nuanced. This initiative highlighted several truths about successful digital worker implementation:

1️⃣ Training is as much about guardrails as it is about knowledge.
It’s not enough to train the digital worker on what to say. You must also rigorously define what not to say. GAbby’s early responses hallucinated offerings (like free project management courses) simply because adjacent words appeared together in queries. When AI can access broad public data, constraining its knowledge base to reliable, vetted sources is critical for brand trust and compliance.

2️⃣ Words matter more than ever.
Changing “SMS” to “text message” seems trivial, but this small fix made the agent feel more relatable. The language used by AI must reflect your customer’s voice, not robotic syntax. The user experience is judged on tone as much as accuracy.

3️⃣ Cross-functional collaboration is non-negotiable.
This wasn’t just a “tech project.” Ops leaders framed user scenarios. UX experts evaluated conversation flow. Engineers handled system constraints and testing. Vendors (thx OutRival) contributed platform and expertise. Success only came when these perspectives aligned, especially around what “done” truly looked like.

4️⃣ Personalization requires planning.
Personalizing conversations based on previous interactions or user data makes agents feel smarter, but only if the underlying CRM hooks, lead mapping, and data flows are in place. GAbby’s ability to personalize is promising, but it must be stress-tested across real-world variations and we know iteration is coming.

5️⃣ Launching isn’t the end, it’s the beginning.
Everyone involved treated this launch not as a final product but as a live experiment. There was an openness to iterate based on real interactions. That mindset (launch, listen, learn, and improve) is essential to evolving a digital worker from functional to exceptional.

Digital workers (like GAbby) will increasingly become teammates in service and sales. But without intentional training, thoughtful language design, and tight operational alignment, they risk becoming more alienating than helpful. As this project showed, the AI is only as good as the humans who build, guide, and refine it.

Lessons from an Automation Fail

Jourdan Hathaway Leave a comment

Many years ago, I had an epic automation fail that taught me a big lesson in tech implementations. It’s the kind of lesson you only need to learn once before it changes your understanding of the success drivers during digital transformation. My buddy Corey Miller would refer to this as a Red Learn (fail) and a Green Learn (growth).

I’m an operator, so naturally I look for ways to drive efficiency, optimizations, and scale.

Imagine you had to manually send out application deadline emails every 8 weeks, for 800+ different online programs, across 60+ education institutions day in and day out. This is a perfect use case for email automation (table stakes today, but novel back in the day). Let’s zip past the 💪Herculean effort to gather business requirements, select the vendor, do the implementation and customer config. This isn’t about that.

Let’s just get to the part where we built a great master template that had a bidirectional sync with all the necessary compliance, content, and data to power a single automated program (where operators swoon). This template pulled in 26 dynamic content field to ensure it matched the right program and institution – things like, the actual deadline date, the school name, the logo, the program name, the key value props, tuition cost, apply now link, etc.

So what happened?

The automated program worked as intended technically speaking. But here’s where the ‘uh-oh’s were:

  • Among those 800 different program names? Masters of Business Intelligence was spelled wrong (🤦‍♀️face palm for being spelled Intellgence) in the original CRM set up that it pulled from. That field was never intended to be public facing and so it wasn’t QA’d back in the day. Just correct the typo you say? We did, which then broke 11 different business reports that were integrated with that data field. Other departments depended on those reports – not great.
  • How about that easy date field? 🤦‍♀️Uh-oh, we didn’t accommodate the day/month vs month/day formats across countries. We just manually knew to reformat.
  • How about that tuition field? 🤦‍♀️Uh-oh, we didn’t have a data governance protocol for ensuring all 800 programs were maintained with price adjustments as time went on.
  • How about that Apply Now link? 🤦‍♀️Uh-oh, several pointed to a URL that we didn’t have control over and no mechanism to know if it changed and thus gave recipients a 404.

Here’s the big learn: Your data is the foundation of success; so are the business processes around data governance and maintenance. Do not underestimate this part. If you’ve seen this movie before, it doesn’t matter what tech project you’re working on, you enter it with a healthy respect for your data strategy.

It’s also why you know that implementation will be 20-30% longer that that lovely original timeline if your data strategy is not ready. But, this all solvable. And it’s a skill. So go thank and fist bump the Business Analysts, Data Folks, PMs, Delivery, and Process/Workflow people in your life.

What makes a team high-functioning?

Jourdan Hathaway Leave a comment

“Ok, here’s the roadblock, but we can totally figure this out. I have a plan on how we can tackle it.” ⏳ 4 hours later…..

“Ok team, thanks for the rapid problem-solving meeting. We’ve now prosecuted the plan. Triage is underway. To recap, I’ll do this. You take that. She’ll own this part. He’ll own that other part. Now let’s go deliver! We’ve got this. See you back here in 24 hours to confirm our collective resolution and success.”

What to do when you hit that inevitable project roadblock

The above are conversations that transpired on a super thorny, complicated, tech project. Hitting a roadblock on a technical project itself is never a surprise. C’mon, you know the kind – tons of systems, tons of competing priorities, tons of stakeholders, not enough time, unforeseen downstream impacts of something not operating as intended (say what? never). Then that heat that envelopes a team nearing the go-live deadline – and 💥 – big roadblock emerges and someone has to call an audible.

We overcame such a project this week and it had me thinking about what makes a team high-functioning. I saw it in action. I was in the thick of it with them (and I’m morbidly captivated to moments like this because I’m obsessed with the power of human connection and its resulting achievements). Days later, I’m still reflecting on how proud I am of what the team overcame and ultimately accomplished – not just the ‘what’, but our ways of working (and treating each other) while doing the ‘what’.

I’ve routinely noticed 2 FEELINGS that make all the difference:

  1. Trust (I trust my co-worker to do his/her part and they can count on me to do mine)
  2. Winner’s Mindset (I believe we can conquer this and find a successful path forward)

High functioning team members have innate accountability

My next observation after calling the audible was our Head of Product Marketing saying, “I understand the roadblock and I have a triage plan we could rapidly execute to navigate this. It comes with tradeoffs so let’s assemble the team now and prosecute it.” She did this unasked with total ownership. Then our Senior Technical Product Manager did the same thing, but on the technical side.

Back the “what” – here’s what the team did:

uh-oh moment ➡️ project audible called ➡️ roadblock identification ➡️ areas of ownership established ➡️ rapid problem-solving as a group ➡️ plan created ➡️ tradeoffs explored ➡️ expectation setting ➡️ stakeholder alignment on triage-plan ➡️ divide and conquer to execute ➡️ plan activated

This all happened in hours – not days and weeks, HOURS.

Today we celebrated that we ‘did the thing’. Internal comms went out about our go-live and the action plan to finalize all the remaining to-dos. Remember those tradeoffs? People typically won’t be upset about tradeoffs so long as you set clear expectations and get buy-in along the way.

This is where it’s important to have durable skills, not only hard technical skills.