#everything makes sense until you put semantics up to the implementation | Explore Tumblr posts and blogs

xiubaek-13 · 5 years ago

Text

Unusual Suspects

Prompt: Minseok (feat Baekhyun, sorrynotsorry) + “You taste like fucking candy.” + “You heard me. Take it off.”

Setting/AU: Vampire

Warnings: it’s kind of a crack drabble, mentions of blood & death, supernatural themes, swearing, standard vampire stuff, implied smut.

Word Count: 2,366

A/N: Again, sorry this took so long anon, I hope you enjoy it. The idea was originally going to be a witch/wizard au but the vampire one came to me after seeing this prompt and I kept laughing about it so I had to make it happen.

***

Knock knock.

You groan from underneath the pillow you’d put over your head in an attempt to block out the incessant knocking at your front door. Who the fuck door knocks at this time of night? You sleepily grabbed your phone, the screen illuminating, temporarily blinding you while showing you the ungodly hour of 3am.

Knock knock.

Three in the fucking morning. You had no missed calls, unread messages or anything to indicate that someone needed you, and really, if they needed you then odds were that they also knew where your spare key was kept and would just let themselves in.

Knock knock.

You threw the covers off in a huff, half asleep, barely human and 100% pissed off - like a cat when it has to have a bath. You got up and stumbled to the door, your equilibrium not quite caught up to the fact that your body was upright and moving. You did pretty well to only fall into the wall twice.

Your hair was a mess and you probably had drool on your face but those were things that alert people considered, not abruptly awoken in the middle of the goddamned night people. Those people only had three thoughts - Do I need to pee? Who do I kill for waking me? And Can I go back to sleep now?. You flung the door open - again, alert people would probably have some sense of self preservation and maybe not open the door at 3am to complete strangers - and grumpily sized up the two people in front of you. Why the fuck did they look so pleasant and AWAKE? The two men in front of you seemed pleasantly surprised that you’d opened the door.

They didn’t look at you like they’d spent the better part of fifteen minutes knocking on your front door, no they looked like the picture perfect missionaries who usually woke you up (at a much more reasonable hour of 8 or 9am). One wore white, the other wore black. Both had black hair, styled more than your standard missionary would have theirs but who knew what the hell these two did given they were knocking on your goddamned door at 3am, maybe they were a bit vain, you didn’t care. They looked rather harmless to you in your current state. The only thing that stood out were their eyes, those were far too intense for your standard missionaries, even your barely awake, murderous self could see that. Still, there were people knocking on your door at 3am who looked poised to try and sell you on the word of god and you were not having it. Jesus would want you to be well rested if he expected you to follow the thou shalt not murder commandment.

All you wanted was to go back to bed and be left alone. 3am was not time for a conversation on your doorstep. You wanted them gone, the sooner the better. “Seriously, what the hell do yo-”

The one in white smiled sweetly at you as he stepped forward and asked. “Hello! Do you have a minute to talk about Dracula?”

You couldn’t believe you were about to shut down the messengers of god this early in the morning but here you were. Normally you played along then gave some witty remark about making a deal with a crossroads demon or telling them that you were actually the antichrist, or that you were waiting for your human sacrifice to turn up. Those were always post coffee conversations, when your wit was less bitchy. These two weren’t getting any of that treatment today. No, you were going to keep it short and sweet. A simple ‘no’ then you could close the door and go back to bed. “No- wait, Dracula?” Well that was unexpected. It did explain the stupid hour of the day though.

“Yes!” The one in black stepped forward as well, smiling warmly, happy that you’d basically recanted your rejection of their presence.

“You’re vampires?” You asked. You weren’t quite awake enough to remember two very, very important things. 1. Vampires were not real and 2. If they were by some weird twist of fate, actually real vampires, then you most definitely should not invite them in. You should close the door, go back to bed and sleep it off. You didn’t do that though, instead opting to rub your eyes and take a proper look at these alleged vampires. The one in white was slightly taller than the other. He had broad shoulders, dark tousled hair, khol lined eyes & a lean body. Everything about him appealed to you, which made sense if you were to believe that he was a creature of the night. You could happily ogle him for hours but you mind reminded you that a) it was rude to stare and b) there was another man for you to roam your eyes over. You stared at him unabashedly which didn’t seem to unnerve him, if anything it interested him. He was only slightly taller than you, with dark hair that fell into his feline eyes, which were also lined, but with a smoky red liner. His black shirt clung to him and you could see that whilst he wasn’t as tall as his partner, he was muscular.

As you stared at the two men the one in black smirked at you and spoke softly. “Yes. We have pamphlets.” As he spoke the other held out one of the aforementioned pamphlets in his delicate fingers. This whole encounter so far was utterly ludicrous.

You took it from him and flipped it over in your hands, confused as the logical part of your brain tried to get through to you. “Vampires have missionaries?” The concept seemed utterly stupid. Vampires were the fictional beasts from gothic horror. They were entities with powers that were almost unmatched, not quiet door to door missionaries like the pair standing in front of you. Still, you had questions. Even if they were scamming you, they had piqued your interest.

“Where else would new vampires come from?” The taller of the two asked, cocking his head to the side as he laughed lightly at your question like you were the one saying crazy outlandish things.

“I assumed you bit people.” You shrugged. If you were to believe the tales from your childhood, vampires - still fictional - created more of their kind by biting someone and draining them of their blood, and once the person was at death’s door they fed them some of their blood. Then they let them die. Once the victim died the blood in their system would raise them as a new baby vampire. The stories were always like this, some small variations existed here and there but what do semantics matter when the whole concept is fictional?

The shorter one frowned slightly at your response and nodded, clasping his hands behind him. “There are many harmful stereotypes. May we come in?”

“I guess.” Was your stupid answer, stupid because had you been more awake or even remotely concerned for your safety you would have never let two strangers into your home during the day, let alone at 3 in the goddamned morning. But the words fell out of your mouth before you could stop them. Not even five minutes ago you’d been ready to tell whoever was at your door exactly where they could go and/or what implement to shove up their own ass so that you could get yourself back into bed and back to sleep but here you were, stepping aside to let the two men (whose names you hadn’t bothered to ask because manners were also apparently not a thing right now) enter your home.

You led them to your kitchen and started to pour yourself a glass of juice. “Should I offer either of you a drink or is that a little on the nose?”

The taller one laughed and shook his head. “And she’s funny at 3am, I like her.”

“I must apologise for my partner. He appears to have forgotten his manners. My name is Xiumin & this is Baekhyun.” He inclined his head towards his partner who just seemed happy to be indoors.

“We don’t usually get this far to be honest. People usually say some rather crude things to us.” Baekhyun looked around the room, his eyes shining. “You have a lovely home.”

“Thanks? It’s a mess right now but it’s super early or super late, who the hell knows, and I wasn’t expecting guests.” You stifle a yawn as you vaguely gesture around the room.

Xiumin stepped forward, drawing your attention back to him. His sharp gaze held you in your spot as he smirked and closed the gap between the two of you. “You know, you really should be more careful. Letting two complete strangers into your home at any hour is a risk but in the dead of the night after they told you they were vampires? That’s downright stupid.”

You froze as you finally realised the position you were in. Whilst they weren’t hulking muscle pigs you were outnumbered and you were pretty sure they were still stronger than you. “The vampire thing is a joke though, right?” You half heartedly laughed. “I mean they aren’t real…”

You turned your head as you heard Baekhyun chuckle from across the room as he inspected some of the photos you had pinned to a board. He paused with a photo of you and your best friend in his hands and looked at you, his eyes darker and more menacing than before. “Oh my dear, vampires are very real. We’ve just had to amend our methods of conversion over the years.” Your eyes widened in fear as you spotted his fangs as he spoke. “We figured it worked so well for the church over the years, so why not try it. We increase both our numbers and our real estate portfolio for every home we’re invited into.”

You were scared, there was no point in denying that fact, but the more time you spent with the two of them, the more comfortable you felt in their presence. The longer they spoke to you, the less terrified you became. You figured you’d try to keep them talking until that fear subsided a bit more. Then you’d be able to work out a way out of this, negotiate with them or something.

You kept them talking, asking their answers to other common stereotypes associated with vampires. You figured they’d have to have them in case someone didn’t let them into their home but still wanted to talk. Their answers were so well formulated and convincing that it almost undid the two and a half decades of fear mongering you’d been fed. Almost. Twenty minutes later, you were still terrified and fearing for your life. You didn’t want to die yet, you still had recipes you wanted to make and what good were they if you couldn’t stomach food anymore? Would animals hate you if you were a vampire? You’d sooner die and have that be it than live out an existence where every dog and cat hated you.

You must have given a voice to those fears because you heard Baekhyun chuckle again as he moved back across the room towards you. “You shouldn’t be scared little one.” Xiumin sighed as he continued to stare at you. “We’ve been watching you and think that you’d make the perfect addition to our little family. I promise, we’ll let you enjoy your time with us before we turn you. You’re less likely to hate us after if we show you how good one of our kind can make you feel.”

“And who said we have to turn you tonight?” Baekhyun added. “Darling, we have so much planned. We can take our time, work out all of these niggling human concerns of yours.”

Xiumin held your face in his hands. “Tell me no after I kiss you and we’ll turn you now, but if you tell me yes then you’ll have a night that you won’t regret.” He attached his lips to yours. You felt the soft, plush lips against yours and strangely the fear you had started to dissipate. He didn’t force the kiss, seemingly waiting until you either pushed him away or made a move to show him you wanted to continue. Either way, you were going to die tonight. That much had been made clear. The choice had been made and there was no way you were going to be able to fend off two vampires and not die a horribly painful death. In the back of your mind your brain gave you two options, either die now or let them give you pleasure before dying. It even threw in the possibility that you were still dreaming and if you were dreaming then you’d obviously go for the option of sex with two hot vampires.

You settled on throwing caution to the wind, something you’d done a lot tonight, and responded to his movements allowing him to take your bottom lip between his teeth, his tongue swiping along it. He released your lip and kissed you again, this time deepening the kiss. He varied the pressure he applied, giving you soft kisses then deep hungry, breath stealing kisses. When you eventually broke the kiss you were panting as you tried to catch your breath. You meant to ask make a witty comment about how that was a bold move for a missionary but what came out of your mouth was more of a moan than words.

He trailed kisses from your mouth down to your neck, nipping and sucking at your flesh. “You taste like fucking candy.” He groaned into your shoulder as he momentarily stopped himself.

His voice was a low rasp and you thought he’d said something but you were too caught up in how his mouth felt against your skin and didn’t hear him. “Sorry what?”

“You heard me. Take it off.”

36 notes · View notes

brianobrienny · 4 years ago

Text

How Agile Management Helps Achieve Sales And Marketing Alignment

As the teams we coach mature in their use of Agile practices, they begin to notice an improvement in how they communicate with adjacent departments and teams.

For marketers, that is most often reflected in a sense of increased alignment with Sales, a typical internal stakeholder and a main source of external requests for marketers. Better communication and the ability to work towards common goals in a harmonious way is strengthened even further if the Sales department has also adopted Agile ways of working.

To delve deeper on this topic and explore how Agile management is helping Sales and Marketing do more, and better, together we decided to turn to a colleague who has been navigating the interdepartmental relationship between Sales & Marketing for a big chunk of his career.

In this exclusive interview for the AgileSherpas blog, Anthony Coppedge, currently the Agile Transformation Lead for Digital Sales at IBM, is sharing his experience of the effects of Agile management across the business units.

How would you describe the typical relationship between Sales & Marketing within an organization? What works well? What doesn’t?

The ‘typical’ relationship is always a reflection of the culture of Sales & Marketing in any organization. As such, it’s easy to generalize the two groups into a continuum: combative to collaborative.

Combative relational differences surface when there’s a silo mentality of ‘us’ vs. ‘them’ which is often seen as Sales AND Marketing; two distinctly different camps with different objectives.

What works well is when the focus is on Sales WITH Marketing, not Sales AND Marketing. The difference is not semantics, but operational. Instead of a siloed approach (‘us’ vs. ‘them’), it’s ‘we’ together. This happens when there is a shared view of the customer, a shared and aligned vision from leadership, and a shared and coordinated operation through coordination. What works well is a unified focus on continuously improving towards the same objectives, even when that includes different metrics.

Agile as a way of thinking – a mindset – breaks down the artificial territorial silos by uniting the different roles under a common, customer-centric alignment. I describe this as a sequential process for creating and maintaining alignment through Mission, Objectives, Goals, Strategies, and Actions (MOGSA) (see more below).

What are some of the alignment challenges you have observed between Sales & Marketing within the businesses you’ve coached?

The alignment challenges are based on two key factors: culture and purpose, which are present in teams and organizations of all sizes. I’ve worked with a huge range of organizations from Enterprises to small businesses to everything in between, and it always comes back to culture and purpose.

Culture is not what a leader says it is; it is what each person experiences by and through the actions of others at every level of the organization. Agile is, at its core, a culture play because true business agility is a mindset, not a system. When someone changes their mind, the behaviors will follow. But without a change of mind, behavior modification will always revert back to the ‘old way’ when pressure is applied.

My friend and fellow agilist at IBM, Andrew Burrows, says it this way: “Agile prioritizes through friction.” If you have a healthy culture, this friction happens with empathy, trust, respect, openness, and courage. If you have an unhealthy culture, friction will lead to stand-offs and a winner and a loser. No matter the culture you have, culture always wins, so change the culture to change everything else.

Process alignment is a mix of shared Objectives (Where are we going together?), Goals (How much and by when to get there together?), Strategies (What are ways we can align together?), and Actions (Who does what and how do we communicate, coordinate, and collaborate together?). The customer is on a continuous customer journey, and on that continuum are both Marketing and Sales.

With an agility mindset, the shift of processes is transformed from a linear hand-off (from Marketing to Sales) into a new way of working that is cyclical and coordinated without ever ‘arriving’; the journey is the way to define the process.

How does a lack of alignment between these two adjacent departments hold the organization back? Does it hold Marketing & Sales back?

Without alignment, functional and cultural silos exist in both practices and systems. While I try to remain tool-agnostic in my leadership and coaching, the integration of key systems (tools) and processes is the only way to scale operationally. Without some level of automation, the wasted effort results in a lack of trust around the data and frustrates the marketers and sellers, which further erodes trust.

Our work should unite us, not divide us.

However, until and unless there is clarity around the shared purpose of both focusing on adding value to the customer during their entire journey (including repeat sales, upsells, new campaigns, etc.) combined with a shared organizational mission, conflicting interests will be manifested through differing motivations (compensation plans, anyone?) and even different outcomes.

From your perspective, what are the key benefits of having Sales & Marketing working harmoniously in alignment with organizational strategy and each other?

Both Sales and Marketing should want to see the same successful outcome: a satisfied client who is so delighted that they’re willing to be a promoter of who you are and what you do.

What often happens in organizations of all sizes is a focus on outputs instead of outcomes. Because of this, the outputs of Marketing might be limited to things like conversion rates or campaign performance metrics. However, these are only outputs of doing activity; they’re not outcomes.

Sales will often look at activity metrics, too, such as call logs, emails sent, and social touches as a proxy for outcomes but usually end up being busy though not particularly effective.

Remember that customer journey continuum mentioned above? An agility mindset promotes alignment for Sales with Marketing, which creates a continuous loop of serving and adding value to the customer. This focus keeps the customer at the center of the never-ending process of continual improvement.Without a shared mindset and coordinated way of working (via business agility), Marketing will always hand off to Sales and forget about the Client in favor of finding new Prospects. With agility, it’s not either/or, but both/and.

Why is Agile management a good tool for achieving alignment between Sales and Marketing as departments?

Marketing and Sales are only ‘departments’ inside the company; the client makes no such distinction because they simply interact with the brand. Why would we create an artificial barrier if the client doesn’t need it? I submit that in a digital world, the functional differences between Marketing and Sales are no longer sufficient to declare the need for two different organizations within the larger organization — even in an Enterprise-sized business — because an aligned culture of agility fosters communication, coordination, and collaboration without the hassle of crossing organizational boundaries, budgets, or bureaucracies.

Agile management is almost an oxymoron, not because Agile doesn’t need managers; it simply doesn’t need the traditional sense of management telling everyone what to do. Self-directed individuals and teams benefit from servant leaders providing clarity, managers as impediment-removers, and processes and systems which are changed and updated directly from marketer and seller feedback.

In comparison to Marketing, where Agile is becoming a more popular methodology, has there been a move towards Agile ways of working within Sales?

Even in 2020, it’s early days for Agile Sales because of both the challenges of changing long-standing cultures and the shift in compensation models to reflect the modern realities of Sales…especially Digital Sales.

However, I would say that doing Agile isn’t nearly the same as being Agile, so it would be unhelpful to think of Agile Marketing or Agile Sales as a methodology.

When a method is put in place, it automatically comes with rules and rigidity, which will lead to whatever is implemented as partially or wholly being anti-Agile. Instead, being Agile implies that the mindset results in consistently better outcomes over time through small, iterative steps, and that can operationally look like a number of Agile frameworks. In my experience, a hybrid approach to Agile frameworks promotes an open-handed implementation of new ways of working instead of a close-fisted methodology of one flavor of Agile practices.

To be Agile is, by definition, to be nimble. I submit that organizational flexibility and adaptability are now table stakes to keep up with not only the amount of change but to be capable of moving at the speed of change.

From a management viewpoint, Agile Marketing with Agile Sales is not top-down nor is it bottom-up; rather, it is an infusion. My friend Evan Leybourn, who is himself a former IBMer and the founder of the Business Agility Institute, introduced me to the concept of infusion (link: https://businessagility.institute/discover/on-false-dichotomies/) and I believe that without complete buy-in from both Management and Sellers, the realization of Agile Sales is likely improbable. It’s all-in. As Michelle Peluso, Marketing SVP and CMO at IBM says, “Agile to the core” is the mindset required to face the new realities of business.

Which Agile practices have you identified as particularly helpful to align Sales and Marketing strategically?

I may be scolded by some for not answering this question with Agile Practices (‘just tell us what to do, Anthony‘ is a refrain I hear often — but doing so would be anti-Agile).

Instead, I will answer the question with Principles. What’s helpful is the most basic of agreements: a unified clarity of purpose, an insatiable curiosity to iterate and improve, and a focus on self-directed action. If those three principles — or others if it helps your organization — are truly agreed upon, then you’ll discover the Practices that make sense in your unique context.

I can’t tell you how to be successful; I can only help you identify what it will take to learn how to be effective.

Does the Agile implementation look similar in Sales as it does in Marketing? What are the differences?

Yes. It is similar because the Principles and Values are the same — identical — for both.

The differences in execution have more to do with operationalizing the systems, tools, and processes to reflect a unified way of working towards the same Mission and shared Objectives, even when the execution of those will inherently be different.

Agile is Agile is Agile.

Agile is a belief, not a methodology, so we focus on what we have in common (the customer, our Principles, our Values, our Culture, etc.) and find ways to distill the transformation into clarity, adoption, innovation, and continuous iterative improvement.

Could you share any successful examples of Agile management uniting Sales & Marketing in high(er) performance within organizations you’ve worked with or observed?

When there has been a wholesale commitment to aligning with an Agile mindset, the results have been astonishing in two ways.

First, identifying what’s not working is the early set of ‘wins’ because when you find yourself in a hole, the first order of business is to stop digging. This creates an immediate gain because at least one of the biggest sources of waste has been identified and rectified early on. This often leads to some surprisingly significant gains by simply ‘buying back’ lost time and resources, which also is a nice boost to morale!

The second benefit is that a new kind of feedback loop is introduced and acted upon regularly. Once again I quote my friend and fellow agilist Andrew Burrows, as he says it so eloquently: Strategy cascades down and learning flows back up. When this happens, those strategies are changed based on feedback from the very people doing the work. This cycle repeats continuously so that strategy and execution are continuously improved. That’s the infusion Evan talks about.

Agile in Action

After only six months of being Agile, a small team of marketers and sellers I led in 2016 applied business agility and had some huge learnings that led to some amazing performances:

They doubled the number of emails sent per month while increasing the click-through rate by 62% at the same time, which lead to…

Shifting the focus to creating more (and more granular) landing pages which saw a 342% increase in landing page views with a 565% growth in form completions, which lead to…

5x increase in qualified leads and over 2x increase in the Sales pipeline.

A SaaS organization implemented Agile and rapidly went from trying to adopt a single framework (Scrum) to a hybrid approach within two quarters:

This provided line-of-sight to the disconnect between content marketing needs from both Sales and Customer Services and Marketing content creators, which led to…

Using ROI metrics to calculate and hire additional staff and increase the Marketing output more than 6x (with only 3 new hires), which led to…

Both Sales and Customer Service leveraging unified tools and more quality content to more specifically and accurately meet the pain points of prospects and clients with targeted, timely resources.

Though those are some great examples of some relatively fast improvements, the larger the organization, the greater the technical debt (legacy systems) and the greater the cultural debt (a culture built on what used to work). Agility at scale is difficult because of the sheer enormity and momentum of established ways of working. In these scenarios, a more patient view is required to identify and assess what is possible to change, what is probable to influence, and what is of concern that must be reimagined in order to not fight legacy headwinds.

Agile will result in faster change, but speed is a by-product and not the point. Doing the wrong thing even faster is not a success. Agile is an all-in pull to admit that what got you here won’t get you there in the digital future rather than a siloed roll-out push to force change.

Any helpful resources you can share on this topic?

Business Agility Institute

The Marketing Agility Podcast with Roland Smart and Frank Days

“Death of a Marketer” by Andrea Fryrear

About Anthony Coppedge

I’m based out of Fort Worth, Texas where I work remotely when not traveling for IBM, where I lead the Agile Transformation for Digital Sales. Most of my brain power coaching marketers and consulting Sales & Marketing teams on implementing an Agile mindset, which means I teach leaders, managers, and teams on how to manage the tension between planned and unplanned work so that they can deliver value faster. I fuel my heart by mentoring young leaders and writing for a variety of audiences. I value empathetic leadership, have an odd penchant for Oxford commas, and I think Chips Deluxe cookies taste so good the tiny Keebler Elves should be taken seriously.

The post How Agile Management Helps Sales & Marketing Align Around Common Goals appeared first on AgileSherpas.

The post How Agile Management Helps Achieve Sales And Marketing Alignment appeared first on Marketing Insider Group.

How Agile Management Helps Achieve Sales And Marketing Alignment published first on http://rssmix.com/u/11592782/rss.xml

#Internet Marketing #Social Media Marketing #Email Marketing #Business

0 notes

touristguidebuzz · 7 years ago

Text

Airlines Put Facebook Messenger Chatbots to Work Answering Easy Questions

Lufthansa Group is one of several airlines using bots to respond to Facebook Messenger queries. The company is trying to make the bots as human-like as possible. Lufthansa Group

Skift Take: Bots have come a long way since Alaska Airlines introduced 'Ask Jenn' about a decade ago. But they're still not perfect. At least for now, we'd rather have a human touch.

— Brian Sumers

Every day, 10,000 customers contact Aeromexico to ask questions, and many — such as “Is there a charge for checking a bag?” — are so simple they don’t require a human response.

So about a year ago, Aeromexico started using a Facebook Messenger chatbot to answer these types of questions, loading an artificial intelligence “brain” with 500 common responses, chosen from Facebook, Twitter, and telephone transcripts. The platform serves about 1,000 Spanish-speaking customers per day, handling roughly as many inquiries as two full-time employees could but at a cheaper cost.

“It’s able to interpret any of the ways that any human could ask questions and determine what they’re trying to ask and match it with one of the answers,” said Brian Gross, Aeromexico’s vice president for digital innovation and strategy.

Like a lot of newish tech, it’s not perfect. Gross stumped it recently by using an offensive Mexican phrase, and the bot told him it didn’t understand. It’s also not fully equipped to answer some common questions, including “How do I change my flight?”

It can respond, but it directs passengers to regular customer service channels. The answer is similar for bag fees, with the bot transferring customers to the airline’s website rather than helping passengers pay what they owe. And while the bot can look up flights for sale, it will send travelers to the website to buy them.

Eventually, Gross expects the bot to improve, and perhaps help solve basic issues from start to finish. Several other airlines are also using or testing Facebook Messenger chatbots, including Volaris, a Mexican discounter, Lufthansa Group, and KLM. Some bots answer questions, while others allow passengers to buy tickets or receive flight status updates.

For now, most airlines are focused on Messenger, since implementing bots on Facebook is easier than on other services. But in the future, some airlines want to develop programs for Whatsapp and WeChat.

Bots have already improved markedly since early versions like Alaska Airlines’ Ask Jenn, which debuted almost a decade ago. Over time, experts say bots should become even more human-like, and be better able to help customers buy tickets, pay for baggage and change their flights. They argue that bots should be able to do everything agents can.

“Yes, you can have the bot with some answers to some questions,” said Inaki Uriz, CEO of Caravelo, the company that helped Volaris build its bot. “If people actually ask about those things, they get the answer. That’s the approach that many airlines have followed until now. But we believe our chatbot has to be an airline assistant. It has to know you. It has to do everything you want.”

CUSTOMERS ASK THE SAME QUESTIONS

In the short term, having bots respond to basic questions makes the most senses since about 80 percent of passengers ask the same things, Uriz said.

Often, passengers want to know about baggage fees and whether they can bring a bicycle. Or they want to know how early to arrive at the airport or what to expect from security checks. Sometimes they want to know about where the airline flies, and how they can change their flights.

“For that you can have a bot that can have straight precise and even rich answers,” Uriz said.

At Aeromexico, the bot handles these queries without difficulty, Gross said.

“You have people coming in with simple questions and the brain is able to match it with an answer, and that’s the answer,” he said. “For example, for baggage allowance, you can have a human typing out all this stuff, or you could just show them, ‘Here’s what you can take.’ I don’t see the point of a human doing it.”

Uriz said about 15 percent of requests are “unusual,” making them difficult but not impossible to handle. “You cannot have a direct answer,” he said. In these cases, the bot can do a “semantic search” on the airline’s website, and usually share information that may help the customer. Sometimes, the bot picks up on answers in the frequently asked questions section of the site.

Only about 5 percent of questions are “real craziness,” Uriz said. In those cases, his company’s bot will hand over the question to a human. Some questions are legitimate — if convoluted — while others are not.

“We get a lot of cursing, vulgarity, and we get a lot of sexual innuendo,” Aeromexico’s Gross said. (He notes human agents receive the same abuse.)

Of course, bots still make mistakes — perhaps more than humans. But it’s still early for the technology, and executives say it makes sense to be transparent about what bots can — and cannot — accomplish. They generally recommend airlines tell customers they’re interacting with a bot, and not try to pretend it’s an agent.

“We will be told that chatbots are here and flawless and they will change everything,” Uriz said. “And of course they are not. At least not today. We need to manage expectations and say, ‘In some cases, it is better than dealing with a human and in some cases, it is not.'”

Uriz, who also works with Thomas Cook Airlines, Condor, Finnair and Tigerair Australia, said he sometimes meets with airline executives who try to confuse the bot by asking convoluted questions. They often succeed, but he argues their attempts don’t prove anything, since humans usually ask straight-forward questions when they need a simple answer.

“If you really have the need to know about baggage, you will phrase things in a normal way,” he said. [You’ll ask], How many kilos can I bring? With these plain English questions, there is no failure.”

Lufthansa Group named its chatbot Mildred.

Impersonal touch

At KLM, bots work differently. The Dutch airline has a bot that allows passengers to opt into receive flight status information and their itinerary via Messenger. But the bot does not directly respond to customer service inquiries. That’s done by humans — more or less.

“For KLM, the personal feel is something that makes our brand really strong,” said Karlijn Vogel-Meijer, the airline’s social media manager. “We don’t have the money like Emirates or Qatar [Airways] has, but we have that personal feeling.”

Still, it’s not entirely a human-driven process. Instead, KLM uses artificial intelligence to make it easier for humans to respond to queries on Facebook and Twitter. It has built a database with 60,000 common responses, and when a question comes in, the system makes a decision about which answer fits best. An agent can decide whether to use the response or expand on it. If the agent changes the response, the artificial intelligence program picks up on it, and stores it for the future. “The system gets smarter,” she said.

Without using artificial intelligence, it might take KLM too long to respond to customers, Vogel-Meijer said.

“About two years ago, we promised the customer a response within an hour and they were satisfied,” she said. “Right now if they are waiting for 20 minutes, they say, ‘I have been waiting for 20 minutes and my flight has been canceled and I need an answer.'”

KLM could fully automate the process someday, Vogel-Meijer said, but for now airline executives do not think the technology is sophisticated enough to handle true, two-way chats.

“We believe that people who turn to Messenger go there for a conversation,” Vogel-Meijer said. “You had that time when you wanted to buy bread at a bakery because this person knew you. Now, you see that people want to go back to having those conversations, but they do it with the technology of today.”

Lufthansa Group tried to give its bot some human-like qualities, naming her Mildred, and calling her a “friendly lady” with glasses and pink hair tied into a bun. She was designed to help customers search for cheap airfares, much like a travel agent would have years ago.

But at the SAP’s Sapphire Now conference earlier this month, Lufthansa’s head of digital innovations, Torsten Wingenter, told the audience the bot as first designed had a flaw — it answered questions too quickly.

“People were irritated when Mildred was answering too fast because this was not natural so they did not expect such a fast answer,” Wingenter said, according to iTnews, an Australian trade publication.

Because customers weren’t accustomed to interacting with machines, Lufthansa Group had to delay the response time from the bot, Wingenter said. “It might be in the future that people get used to communicating with machines, but right now they’re not used it and so they expect the other side to be more human,” he said.

Still, Uriz said customers will adapt, and many may prefer interacting with machines. He notes customers can be more abrupt with questions, allowing them to save time. They don’t even have to be nice to the machine.

“Maybe you don’t need to be so polite,” he said. “You can be more direct, and more quick. If I am talking to a bot, I don’t need to say, ‘Hi, or thank you.’ I get the answer and that’s it.”

0 notes

symbianosgames · 8 years ago

Link

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community. The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

At Our Machinery we have one simple rule that governs the physical design of the code:

Header files (.h) cannot include other header files

In other words, header files cannot depend on other header files for the types they need. (Except for <inttypes.h> and <stdboolh.> , we make exceptions for those to get the standard uint32_t and bool types.)

This is a pretty extreme choice. Let’s unpack why we made this decision and how we make it work.

To begin with, if you are not familiar with the term, the physical design of a C++ project refers to how the code is broken down into individual .h and .cpp files and how those files are organized on disk — which files include which others, etc. It is related to, but separate from, the logical design which refers to how the components of the system are connected and interact.

Just as with logical design, the primary goal of physical design is to reduce coupling. We want to minimize the dependencies, so that changes in one file don’t have a big impact on other files.

Bad physical design is easy to spot. It happens whenever .cpp files pull in a lot of .h files that they don’t need. Most of the time this happens indirectly. The .cpp file includes something it needs. Then that thing includes more stuff. And the stuff includes even more stuff — completely unrelated to the original problem. Expanding the #includes in such a project can be both scary and enlightening. A few innocent #includes sometimes expand to megabytes of header data once all the recursive inclusion is resolved. This has a number of bad effects:

Compiles are slow. (Modern compilers are smart about caching header data, but there are limits to what they can do.)

Making changes in single header files causes the whole project to recompile.

You sometimes get weird and annoying errors because of name conflicts in the headers you’re unwittingly pulling in (#define min in <windows.h> is a classic).

All of these things make it harder and more cumbersome to make code changes, which is the worst thing you can do to a software project. Software needs to be nimble to stay alive. If the code gets too heavy you need an army of programmers to move it along, which is neither efficient nor fun.

A large part of the reason why people are drawn to scripting languages is the ability to iterate over the code quickly, to make changes and immediately see the results. At Our Machinery, we believe the similar things are possible with high-performance static languages, if you just set things up the right way.

Bad physical design tends to be a creeping issue. In the beginning, when your project is small, compile times are good no matter what, so who cares. When the project gets so big that it starts to be annoying, it is often too late to do anything about it.

Fixing a bad physical design is hard, even if you have a tool that can pinpoint where you should focus your efforts. It typically goes something like this:

Remove a single #include statement.

Insert the forward declarations that might now be needed.

Insert new #include statements that might now be needed (because those files were previously included indirectly by the line you just removed).

If there are any dependencies that can’t be resolved with forward declarations — refactor the code (this could be an arbitrarily complex task, depending on how gnarly the code is).

Make sure the code still compiles.

Make sure the code still compiles on every supported platform and in every supported configuration.

If you had to refactor the code, run tests to make sure you didn’t introduce any new bugs.

That’s a lot of work to remove one single #include statement. And of course, removing a single #include doesn’t have any measurable effect on the compile time or anything else that people care about. You have to repeat this, again and again, hundreds, maybe thousands of times before you start seeing results. It’s thankless, unrewarding grunt work. And if the physical design is already bad, all those compiles you need to do to check if things still work will take a really long time.

Also, while you are slaving away at this, the rest of the team is doing some other work, happily adding new #include statements everywhere. There is a reasonable chance that over the next few months, all the work you just did will be undone.

Physical design is really easy to screw up, but requires concentrated effort and hard work to fix. This means that time and human nature will pretty much guarantee that you are screwed. It’s simple thermodynamics.

So in a lot of large codebases, people essentially just give up and switch to unity builds or something. Once you are in that hole, it might even be the right decision, but that’s not where we want to end up with Our Machinery.

Since the problem is so hard to fix, we need to stop it before it happens. We need rules that people can follow to avoid getting into this mess. But if you look online, most of the rules you find will boil down to something like:

Don’t include more header files than you need

That is good advice, but it as a rule it sucks. It’s too vague. It doesn’t tell you what to do or how to solve problems you encounter. It’s not verifiable. A rule like that will not stop people from just adding #includes until the code compiles. After all, that’s what they “need”. We have:

Vague rules + no enforcement + path of least resistance + human nature → chaos

Rules should be clear enough that it is obvious if the code follows them or not. Even better, they should be machine verifiable. That way, we can just put the rule in the pre-commit hook and be certain that it is always followed.

This is why we use clang-format to format our code. It doesn’t do exactly what we want, but it is close enough that having automatic formatting is worth the trade-off.

(If you want to know — our main gripe with clang-format is that it insists on left flushing pre-processor directives instead of indenting them with the rest of the code. I find this a terrible, unreadable practice — especially when you have nested levels of #ifs and #elses . Maybe we’ll make a patch for it some day, unless someone beats us to the punch.)

All that exposition explains why we went with a simple, unambigous and easy to remember rule:

Header files (.h) cannot include other header files (except for <inttypes.h> and <stdbool.h>)

This rule is simple and clear enough to be machine verifiable and it completely solves the problem of physical design.

Note: Even with this rule we can still have .cpp files that include headers they don’t need, but that’s not really a big problem. If we eliminate headers including other headers we don’t get the big expanding tree of includes — everything stays pretty contained. And it’s easy to remove #includes in a single .cpp file and check if that file still compiles — we don’t have to touch or compile any other part of the project. In fact, it is so easy that we can automate the process.

Not allowing any header file inclusions is a drastic choice, but that is also what I like about it. I think a lot can be learned by picking an interesting idea or philosophy and see just how far we can push it. Even if we don’t make it all the way we will learn a lot of new things by trying.

But does the rule work in practice? Can we actually write header files that don’t depend on types defined in other header files? Let’s look some of the problems you encounter when trying to do that and how we deal with them.

Classes

Classes are tricky. If you write your classes following a strict PIMPL idiom and only put abstract interfaces in the headers you might be able to get away with just forward declarations. But that is kind of a complicated way to write C++. And as soon as you want concrete classes, inheritance, templates or inline functions you start to get into trouble.

Our solution to this is simple — we don’t use classes. Our header files are written in plain old C, C99 to be precise. The implementation files can be either C or C++ — whatever makes sense for that particular piece of code — but the APIs and interfaces are strict C. We have several good reasons for this approach, which I will detail in a future blog post, but the main one is that it gives us better logical decoupling. And presto, we get better physical decoupling too, as we don’t need to worry about class dependencies in the header files.

Templates

One of the reasons why we allow C++ in the implementation files is that templates are a very convenient way of solving certain programming problems. But how can we use templates without having headers include other headers?

First, the templates are only used in the .cpp files. Thus, the .h files never need to include them. Second, the templates themselves are written in .inl files rather than .h files, and we don’t have any rule against .inl files including other .inl files. In other words, you can write a template that depends on another template.

This may seem like just semantic trickery — if we allow .inl file to include .inl files aren’t we just recreating the whole rat’s nest again, just with .inl files instead of .h files?

Actually, I don’t think so. We use .inl files very sparingly — only for template code. We’re in general very conservative about using “advanced C++” features and not at all into template-metaprogramming with trait classes, etc. But templates are convenient for things like arrays and hashes. In fact, we currently have exactly two .inl files in the project — array.inl and hash.inl . Granted, the project is still small, but we don’t expect to add many more.

Inlined functions

What about inlined functions then? Don’t we want to use inlined functions in our header files to improve performance? And in that case, don’t we want to allow headers to include other headers, so that one inlined function can call another and have all those calls optimized away?

Not really. Inline functions are a C++ solution to a C++ problem. “Good C++ design” encourages having many layers of abstraction with simple functions doing trivial things. Then it promises that through inlined functions and optimizing compilers, all those levels of abstraction will be cost-free, since everything will compile down to a few simple assembly instructions. And it actually works most of the time.

But we question the benefits of all those abstraction layers in the first place. As anyone who has tried to step into STL code in the debugger knows, adding abstraction layers does not necessarily make the code easier to understand. On the contrary it can sometimes make you feel lost in a maze, wondering where the real code is. What is the benefit of abstraction if it doesn’t help programmers?

Sure, if you have an interface function Vector3::get_x() , then that function better be inlined, because otherwise you are paying a heavy price for just retrieving a float. But we prefer to write meatier methods in the APIs, that operate on more than one item at a time. For example, instead of get_x(), maybe we have a function for getting the positions of all objects:

// Retrieves pointers to the arrays of x, y and z positions and returns // the total number of items in those arrays. uint32_t get_positions(float **x, float **y, float **z);

This is a part of our data-oriented design philosophy: where there is one, there are many.

With “meatier” functions in the API we don’t have to worry about the function call overhead, because we won’t be calling them a million times. Another interesting thing to note is that while we have to pay the cost of the functional call, this API style makes much more important optimizations possible. For example, with direct access to the coordinate arrays, we can write our processing code using SIMD instructions and gain an immediate 4x speed boost.

OS types

What about OS types then, such as HANDLE , don’t we need to include <windows.h> in order to deal with them?

In our API, we represent all OS types as opaque collections of bits:

struct tm_file_t {uint64_t opaque;};

Then in the implementation files we just memcpy() our HANDLE , or whatever the type is for a particular OS, in and out of the tm_file_t . We make sure to make the tm_file_t structure “big enough” to fit the file handle type in all our supported OSes.

So far, our decision not to allow header files to include other header files has been a great one. Not only has it kept compile times and dependencies down, but we have also found that the strictness that it imposes on the physical design tends to make the logical design clearer and simpler.

We haven’t yet encountered a situation where this approach has led to trouble. We will continue to use it and try to take it all the way to the finished product.

#IFTTT #Blogger

0 notes

symbianosgames · 8 years ago

Link

At Our Machinery we have one simple rule that governs the physical design of the code:

Header files (.h) cannot include other header files

This is a pretty extreme choice. Let’s unpack why we made this decision and how we make it work.

Just as with logical design, the primary goal of physical design is to reduce coupling. We want to minimize the dependencies, so that changes in one file don’t have a big impact on other files.

Compiles are slow. (Modern compilers are smart about caching header data, but there are limits to what they can do.)

Making changes in single header files causes the whole project to recompile.

You sometimes get weird and annoying errors because of name conflicts in the headers you’re unwittingly pulling in (#define min in <windows.h> is a classic).

Fixing a bad physical design is hard, even if you have a tool that can pinpoint where you should focus your efforts. It typically goes something like this:

Remove a single #include statement.

Insert the forward declarations that might now be needed.

Insert new #include statements that might now be needed (because those files were previously included indirectly by the line you just removed).

If there are any dependencies that can’t be resolved with forward declarations — refactor the code (this could be an arbitrarily complex task, depending on how gnarly the code is).

Make sure the code still compiles.

Make sure the code still compiles on every supported platform and in every supported configuration.

If you had to refactor the code, run tests to make sure you didn’t introduce any new bugs.

Don’t include more header files than you need

Vague rules + no enforcement + path of least resistance + human nature → chaos

This is why we use clang-format to format our code. It doesn’t do exactly what we want, but it is close enough that having automatic formatting is worth the trade-off.

All that exposition explains why we went with a simple, unambigous and easy to remember rule:

Header files (.h) cannot include other header files (except for <inttypes.h> and <stdbool.h>)

This rule is simple and clear enough to be machine verifiable and it completely solves the problem of physical design.

Classes

Templates

This may seem like just semantic trickery — if we allow .inl file to include .inl files aren’t we just recreating the whole rat’s nest again, just with .inl files instead of .h files?

Inlined functions

// Retrieves pointers to the arrays of x, y and z positions and returns // the total number of items in those arrays. uint32_t get_positions(float **x, float **y, float **z);

This is a part of our data-oriented design philosophy: where there is one, there are many.

OS types

What about OS types then, such as HANDLE , don’t we need to include <windows.h> in order to deal with them?

In our API, we represent all OS types as opaque collections of bits:

struct tm_file_t {uint64_t opaque;};

We haven’t yet encountered a situation where this approach has led to trouble. We will continue to use it and try to take it all the way to the finished product.

#IFTTT #Blogger

0 notes