When you are first learning about Object Relationships, it can be difficult to understand what type of relationship should exist between objects and how each line of code and variable, works together to create that relationship in the program.

I’ll walk you through a step-by-step example of how relationships operate abstractly and how each part of code works to create this relationship into the code we’re developing. I decided to use the world of Pokémon to illustrate object relationships in Ruby, but the major idea can be understood in other languages as well.

Object relationship is a concept used to describe how different classes that create objects can interact together with other objects that we’ve created. As in real-life, how objects relate to each other varies depending on the relationship each object has with each other. As a programmer, we control how we build these relationships, which we will call the domain model. There are several basic ways in which these models relate to one another — I’m going to dive into the belongs to and the has-many relationships.

When we think about the world of Pokémon we have a Trainer who can be Ash, Brock, or Gary, or any other Pokémon trainer. The individual trainer, let’s say Ash in this example, has many Pokémon: Pikachu, Charizard, Bulbasaur, and many others. Each of these individual Pokémon has its moves, for example, Pikachu’s moves may include Thunder, Thunderbolt, & Quick Attack.

I’ve chosen to focus our domain model around the popular Ash Ketchum as my example, and right now Ash has the following three Pokémon: Pikachu, Charizard, and Bulbasaur. I’ll also be using the word instance of a class and an object to mean the same thing as they can often be used interchangeably.

Ash, is an individual object of our Trainer Class, and the Ash object has its own unique set of attributes specific to that class. What do I mean by object? Think of the Trainer Class as a blueprint that allows you to create unique instances(or copies) of the Trainer class which we can call objects, so Ash is an instance of the Trainer class. Each instance of a Class has attributes that make them unique, for example, what attributes do all trainers have (other than Pokémon)? Some common attributes would be a name, possible nickname, number of pokeballs, trainer level, personality type, items, and amount of money in the trainer’s pocket to name a few.

For simplicity, I’ll focus on a few Trainer attributes for our Ash object, which remember is one instance(or object) of a Trainer with unique properties and attributes.

Now let’s create the trainer Ash object from the Trainer Class in an IRB like this:

From the above, we can return Ash’s name to us like this:

And we can also return the Ash object’s level like this:

As far as modeling our Ash object that was created from the Trainer class to the real world, this isn’t very realistic. A Trainer has much more attributes than just name and their level. One most important attribute that is missing to be a Pokémon trainer is the trainer’s Pokémon. As we can see our program has no knowledge of who our Ash objects pokemon are or even the method to call the Pokémon.

In the world of Pokémon, a Pokémon belong to a Trainer and a Trainer has many Pokémon. How can we model this Pokémon belonging to a Trainer relationship with our code? Let’s give a pokemon attribute to an individual trainer.

The “Belongs To” Relationship

Now that we have a setter and getter for a Trainer’s pokemon attribute, let’s review the data in IRB or Pry again:

Let’s say we want to know the Pokemon’s name.

Looks like the “string” that we assigned to this Ash object pokémon attribute is doesn’t have access to the name method.

Instead of setting the Ash’s pokemon attribute into a string, we can set it to something more useful like a complex object. We can set it equal to Pokémon object. So instead of the pokemon=() method being equal to a string, let’s create a Pokemon class and assign an individual pokemon object to the Ash instance pokemon attributes.

Just like we were able to set the pokemon attribute equal to the string ‘Pikachu” we can set the attribute equal to an instance of the Pokemon class stored in the pikachu variable.

Now we can ask for the type.

Now the relationship between Pokemon and Trainer is almost complete. We’ve established the “belongs to’ relationship. A pokemon has one trainer (in our domain model) so we say a Pokemon belongs to Trainer. We established the relationship by giving the Trainer object a setter and getter for Pokemon.

If we look at the Pokémon flowchart we can see that there are a total of three instances of Pokémon that belong to Ash object. They are connected horizontally because all the elements in the class will have the same attribute types, but the values or specifics of those attributes will be changed depending on the pokemon.

The “Has-Many” Relationship

To build the “has-many” functionality in our trainer class and allow it to have many Pokémon, we have to adjust the class a bit.

We’ve started to build functionality into our Trainer classes to allow it to communicate with the other classes and get many pokemon. How? Look at @pokemons = [] in the initialize method. What is that doing? Every time a new Trainer class is initialized (let’s say our Ash object) the pokemon attribute is an array that is a place to hold many pokemon objects. Think of this as the place that houses where all Ash’s pokémon are. The object part is most important — it’s not just holding a string of a pokemon it’s holding pokemon objects.

Take a look at the above code, and you can see that we added a trainer attribute to the Pokemon class, which in turn is setter and getter. But it hasn’t been included in the initialize method. Why would we do that? The answer is who chooses when a Pokémon is added? Is it the Pokémon or the Trainer? The Trainer, of course.

How do we show that with code? We can go to the Trainer class and add a method to do that.

Let’s focus on the add_pokemon method.

So what is the pokemon argument here? It’s the pokemon object created from Pokemon class. We created this method that takes in an argument of pokemon so the trainer can decide when they add a Pokémon object to their @pokemons array. In the world of Pokémon, it would be when they catch a Pokémon.

Okay, we can look at the next line we have

@pokemons << pokemon

As discussed pokemon represents the pokemon object and @pokemon is an array that we decided to store all the pokemon objects. How do the pokemon objects know which player they have a relationship with? Through the next line.

We have…

pokemon.trainer = self

Let’s break this down

pokémon is the argument we passed with a pokémon object.

pokémon.trainer is using the trainer =() method setter and getter to assign a value to self.

What is self?

Self is the object receiving the method call. If the method is an instance method, self is always the instance that we are working with right now. If the method is a class method, self is going to be the class that the method is acting on.

Taking this information of what self is back to our example.

pokemon.trainer = self

The first question is, where are we? We are in the Trainer class, and we are reading a method we built that is an instance method. We don’t want this method to work for the Trainer class overall, because we want to make sure the particular trainer has access to their pokemon. Furthermore, we are trying to add the pokemon to the object of Trainer called Ash. Therefore, self refers to the Ash object.

We can take a look at the code tested in a terminal line to see it in action of how the relationship works.

In line 1, we are creating a Trainer objected and assigned it to the Ash variable. This Ash object has the name attribute “Ash” and the trainer level attribute at” 10”.

In line 2, we are creating a Pokemon object and assigning it to the pikachu variable. This pikachu variable holds the pikachu object, which has the name attribute “Pikachu” and the type attribute “Electric”.

In line 3, we’re calling the method add_pokemon. We are calling add_pokemon on a particular instance of a Trainer which is Ash and passing the pikachu object as our argument.

In line 4, we are checking if it worked, and we can see that the Ash variable with contains Ash object has a pokemon object inside the array which is the pikachu object;

In lines 5–8, we decided to create two new pokemon objects and named them “charizard” and “bulbasaur” each with their own attributes. In lines 7 and 8 we decided to add each of the objects into the add_pokemon method, and it was successful.

In lines 9, 10, we can see that Ash has three different pokemon objects in the pokemon attribute which is an array, and in line 10 we can see go deeper to just see the attribute data.

What next?

Okay, great, looks like the method works! Remember a Pokémon belong to a Trainer and a Trainer has many Pokémon this relationship was demonstrated. Hope this article helped build your understanding of has-many and belongs-to relationships between two objects in Ruby. Ideally, in the Pokemon world their would more relationships with other Classes in order to truly capture the world of Pokemon.

If you’d like to see a Pokemon CLI Adventure Game that uses these fundamentals, head here to check out the repository. Some key features include the following:

• Ability to catch pokemon and add them to your pokemon list
• Ability to see a list of caught pokemon
• Display Bag
• See current amount of pokedollars
• Shop — V1 — plan to add fully functioning shop to future versions
• Log Out — keeps your save file
• Start Battle — V1 — — plan to add fully functioning battle system to future versions.

Don’t forget to give a 👏 if you enjoyed the read!

How we connect knowledge to your fingertips in Stride

Whether you work in a small team or a larger enterprise juggling and finding the right internal knowledge when you need it is no easy task. And for teams that rely heavily on messaging (which most organizations do), it’s especially easy to allow conversational knowledge to not be turned into institutional knowledge. These days it’s all too common to have business units put into isolated groups that rarely talk, share information, or collaborate. When specific knowledge does need to be found it’s hard to search for the information, know if the information is up-to-date, or worse there can be too much information to sort through. Information just lives in too many places. We created a bot in Stride to tackle this.

If you are thinking of bringing your bot from another platform to Stride, here are some lessons we learned launching our app and how we solved key problems. We’ll cover why we chose to use particular commands, give an architectural overview of the application, and walk through considerations we took when building Obie for Stride.

First, some context

Messaging does a great job of keeping communication in one place. It makes for a great archive of information. We all know how to search; it’s pretty simple. You type in what you are looking to find. The problem? Getting information from the deepest archives is a challenge.

For example, looking for a file you accessed a few weeks ago (noise) while only remembering the topic, a few queries, and a bit of context on the content (signal) but not the file name can be a frustrating experience. You have a good idea of what to look for, but there are a lot of places the file can exist and lots of files with similar topics, queries, and context. How can we impact the signal, and reduce the noise?

At Obie.ai, we tackle this signal and noise issue using messaging, behaviour-based machine learning, and natural language processing to help teams share and access knowledge organization-wide: the bigger the company, the harder the challenge exists of accessing and sharing knowledge. With every search, teams can be more focused and informed with fewer interruptions. Our goal is to ensure employees can get access to relevant knowledge at their fingertips. Whether you have an intranet, Google Drive, GitHub, Confluence, or other Atlassian tools like Trello, knowledge is dispersed and siloed across the organization, making some information inaccessible. Finding information should be an easy process. A defined single source of truth to search for knowledge streamlines the search process for both the employees and organizations looking to make information easier to find so that you can get more done.

We were lucky to have heard from many teams, developers and product managers who use a wide range of productivity, developer, and project management tools about common pitfalls: finding information across sources within an organization can create a virtual firehose of information. People didn’t want more knowledge sources. We needed to figure out how to continually reduce the noise so that people can find what is relevant, quickly.

Our journey building bots on messaging platforms began in 2016. As a team who has been tackling knowledge management for some time now, we feel that messaging has afforded us unique opportunities that we’ve never been able to tackle.

While building Obie from a prototype to a fully functioning Stride app, we learned some tips and tricks that might be useful for those bot developers hoping to transition their bot to Stride or those looking to build something new. Here are a few takeaways from our efforts to create a valuable experience:

1. If you’re building a bot for the first time, try not to bite off too much

After being in the bot ecosystem for some time now, we found that the most useful bots typically provide easy ways to get information or collect information using the conversational interface and other interfaces available to them.

We knew that we had to build a quick prototype with Obie’s knowledge retrieval functionality front and center. The prototype of our Stride app was going to be very simple, but still valuable.

In addition to the send/receive messaging endpoints, it involved leveraging the following Stride APIs:

User Details: Returns useful information about a given user like their real name, email, and photo.

Usage Example

getUser: (cloudId, userId, cb) => {
     auth.getToken((token) => {
         request({
         url:       `https://api.atlassian.com/scim/site/${cloudId}/Users/${userId}`,
         method: 'GET'
         headers: {
            'Authorization': 'Bearer ' + token
         }
      }, (err, httpRsp, body) => {
         if (cb) {
           cb(JSON.parse(body));
         }
       })
    });
}

Conversation rosters: Returns a list of user Ids for users in the given conversation.

Usage Example

getConversationRoster:(cloudId, conversationId, cb) =>{
          auth.getToken((token) => {
                  request({
                          url:
`https://api.atlassian.com/site/${cloudId}/conversation/${conversationId}/roster`,
                          method: ‘GET’,
                          headers: {
                              ‘Authorization’: ‘Bearer ‘ + token
                         }
                  }, (err, httpRsp, body) => {
                           if (cb) {
                                   cb(JSON.parse(body));
                            }
                 });
           });

}

We developed the Alpha in about a week at StrideCon. StrideCon is more or less a hackathon week at Mountain Winery in Saratoga, CA, attended by Stride developers and designers. This experience was a unique and timely opportunity that gave us the resources to move quickly. We had entertained talks internally about working within new APIs and we were interested in understanding what it was like to work within the Stride API. This opportunity helped us understand what it would take to bring Obie from other messaging apps into Stride.We tested it and demoed Obie at StrideCom.

With the help of the Atlassian designers and developers we created a solid proof of concept that helped skyrocket our understanding of the Stride ecosystem. After this experience, we decided to focus on how we were going to translate more of our core product experience into Stride past the Alpha.

2. Communicate early to your users what your bot does

There should be some information that explains the value of your bot (what it can do) communicated early. You’re going to get users installing just to play around, so it’s a good idea to demonstrate or talk about the value very early on. This is especially important if you want users to invest the time in going through a lengthy onboarding process.

We focused heavily on educating users through an onboarding process where we could be as specific as possible so new users understand what the bot can or can’t do. After a design review with the Atlassian team, we made several iterations to the onboarding to ensure we communicated our value proposition much earlier than we initially intended.

3. Make the first impression count

We rely heavily on messaging to introduce users to what Obie can do and we get a sense of users sentiment and first impression — when they are happy and when they are frustrated — using Dashbot, a bot analytics platform that enables developers to measure user engagement, and Amplitude, which allows us to track the web experience of the user experience in addition to the bot experience. We focus extensively on user experience — we measure every click, question, and user reply to make sure the experience with Obie is better than nudging, asking a peer, or going into the knowledge sources directly.

A neat endpoint we use unique to Stride is the built-in configuration status for apps. We make it mandatory for users to complete onboarding/configuration before using Obie. While Obie is awaiting configuration, there is a status indicator beside his app icon in the side toolbar so that the installer is aware that configuration is required before proceeding to use the app fully.

To do this, we use:

Conversation Configuration State: Updates a given conversation’s configuration state, where configured is either “true” or “false”.

Usage Example

updateConversationConfig: (cloudId, conversationId, status, cb) => {
          auth.getToken((token) => {
          request({url: ‘https://api.atlassian.com/app/module/chat/conversation/chat:configuration/obie-config/state',
          method: ‘POST’,
          headers: {
               ‘Authorization’: ‘Bearer ‘ + token,
               ‘Content-Type’: ‘application/json’
           },
           json: {
                 configured: status,
                 context: {
                          cloudId: cloudId,
                          conversationId: conversationId
                  }
             }
           }, (err, httpRsp, body) => {if (cb) {
                  cb();}
            })
            });
}

This configuration status is important for us since in order to have a good experience, users must first configure Obie within their environment. We’ve found that onboarding with Obie is crucial for success; by guiding the user through connecting an integration and performing their first search, they get the feel of how Obie works. Once the user has completed onboarding we unlock Obie for regular use.

4. Sidebars and Cards: Take advantage of new design challenges for unique opportunities

It’s important to think of the type of information you are sending to Stride. Stride has a numerous amount of opportunities to allow developers to display information within its environment. We came up with a unique way to interact with Obie because of what Stride offered.

Stride Sidebar & Cards

Stride Sidebars provide a free for all in terms of design and development. Apps can display custom HTML hosted by your app in the right sidebar, like a list of meetings, relevant documents, or open tasks, to displaying contextual information relevant to the conversation.

We found it useful to display documents related to the search for our particular use case. One thing we took into consideration while embracing the freedom HTML provides was to ensure there is a consistent user experience with Obie and Stride. It’s difficult to create a consistent user experience without guidelines so we used Stride design guidelines to create the consistent user experience the user audience would understand.

We found it beneficial to leverage Stride App Cards. App cards offer information at-a-glance and leverage a wide range of design options. When a user asks Obie a question, instead of showing a list of results within the conversation window, we leveraged the metadata and put this information into an App Card . This user experience ended up being quite favorable even though it wasn’t an experience we were used to. The Sidebar allowed us to avoid making the conversation too crowded by displaying only the top result in the conversation window, and then the rest of the results in the Sidebar.

Related Guides

• Glances and sidebars
• Adding sidebars
• Sidebar style guide
• Sending cards
• Node — Application cards
• Sidebar style guide

Takeaways

Obie integrated into Stride turns Stride into an intelligent source of truth, where you can keep your knowledge up-to-date and access knowledge wherever it lives. In Stride, you can surface relevant information and see how up-to-date information is. Through our focus on listening to our users, relentlessly pursuing a favorable user experience, and making data-driven decisions, we’ve learned that each encounter with a bot builds trust and your goal as you develop your bot is to build a trusted coworker.

We’ve only scratched the surface of the Stride API, but hopefully you’re now sufficiently excited to build something awesome! Even if your mission and product aren’t tied to the things we aim to solve, hopefully our learnings from this process will help inform your decisions about specific aspects of your bot and save you time as you build it in Stride. We’d really love to see how you use it, and if you do create a great bot in Stride (or move your bot over to Stride), don’t forget to let us know on Twitter. If you have any specific questions about the journey feel free to reach out and we’ll be sure to help!

Written by John Kyeremeh, Head of Growth, & edited by the Obie.ai team.

Think other people would benefit from this article? Click the clap to help them find it ❤

Building Obie.ai for Stride was originally published in Obie.ai on Medium, where people are continuing the conversation by highlighting and responding to this story.

The reasons sales teams fail at meeting their quota are all influenced by productivity — this article provides you with insights on how sales reps learn and retain information with the goal of understanding what a 10% increase in productivity has on a sales team.

Designed To Learn As Fast As Possible

The other day I came across a post by Tim Gruffub, the author of the popular blog 25iq.com, on a dozen lessons on growth. He made a lot of great points, but I couldn’t help but identify strongly with one passage in particular:

“If you can run more experiments than the next guy, if you can be hungry for growth, if you can fight and die for every extra user and you stay up late at night to get those extra users, to run those experiments, to get the data, and do it over and over and over again, you will grow faster.” — Alex Schultz.

I bolded the words, “do it over and over and over again, you will grow faster”, for a reason. This resonated with me deeply, I immediately wrote in my notebook in red “Coffee is for closers.”

The quote from the movie Glengarry Glen Ross with Alec Baldwin is perhaps the most referenced sales movie in the last few years. It’s easy to get swept up in the narrative of clear winners and losers when it comes to sales but what if the coffee was available for the whole team? Companies that focus on improving sales productivity as a team while enhancing individual performance and learnings will dominate the battle for business.

I think this summarizes things so well. It might sound crazy because I’ve never met a sales team that says they don’t want all their sales reps to hit quota. Yet, many teams don’t do the things required to get the whole team to succeed. It reminds me a lot of a basketball team where as a team you want everyone to be at their best; you want everyone to play at 100% despite physical pain or fatigue. Each player has the desire, and everyone is equally prepared, but like in today’s basketball teams, usually only one person in the team carries the team and is willing to do the hard work — the results show.

Despite the intention, by not focusing on the team, the pipeline and revenue is impacted. Sales people who regularly kill their quota have done the work; they are so good despite changes in the market or competition — they understand what works and what doesn’t. Indeed, at times the numbers are so much in their favour that the company — and even the rest of the team in general — may not fully understand what behaviors are making this impact. They are the winners, and between them and the rest of the sales team, the question of how you help other reps learn to perform similarly to these Top Performers remains.

Let’s get very basic for a second: sales reps learn and retain information differently. What makes an “A” rep different than a “B” rep and how do we ensure everyone has the resources to win? A way to measure this is by productivity. A good productivity increase is one that generates a lot of business, allowing a team that is currently moving at 50 MPH to move further towards its potential of 100 MPH. Of course, any increase in team productivity would also mean individuals are performing better. Moreover, it’s important to dive deeper into how sales reps learn and access information by focusing on sales behaviors.

Dials. Emails. Demos. Repeat.

For years buyers relied on sales people to communicate with them using three activities to stay informed

1) Dialing the phone

2) Having meeting/demonstrations

3) Sending Emails

While these activities are still highly effective means to communicate with potential customers in the B2B space, it’s important to understand that like any channel of distribution, channel saturation eventually happens, and the impact of these three activities has dropped today as the buyer’s journey changed. Looking at the buyer’s journey in more detail, CEB found out that 57% of the buyer’s journey is complete before the buyer talks to a sales rep. This statistic tells sales teams that they must ensure that the customer understands how a solution will help them do their job better with insights that go beyond product knowledge.

Add Value And Provide Deep Insights

Think of how many sales emails you get daily from sales professionals with similar messaging, not to mention the closing email, ‘right person’ email, ‘animal’ chasing you email, and ‘break-up’ email. Which of these emails, calls, or presentations did you actually take the time to listen to and what about them made you respond? If your sales team is not maximizing value for the buyers, according to SAVA, 74% of potential customers will choose the one that is first to add value. Consumers measure value added by evaluating the reps:

• Market Knowledge — Problem the customer is looking to find a solution for.
• Product Knowledge — How your solution solves the customer’s problem.
• Sales Knowledge — How you present a solution to the problem.

Indeed, when considering how sales reps learn it’s important to ensure the rep can develop the skills to convey these three types of knowledge.

Focus On Using Your Time Wisely

Sales reps usually work in teams with a leaderboard approach to motivate and amplify winning behavior where there is a clear 1st, 2nd, 3rd, and the rest.

Here are two hypothetical 60-person sales teams.

Company A

• Has periodic monthly boot camps (5 new reps onboarded monthly). Onboarding takes about 5–7 weeks. During this time, reps are strictly doing onboarding on the product, competitors, and company culture. The Sales Manager has said that the current onboarding process is not scalable to promote consistent and efficient reps. The organization wants to promote ongoing engagement and professional development to ensure reps stay consistent as reps who were top performers in the past are no longer top performers.

Company B

• Is currently hiring an additional 15 reps who will focus on new business. The organization as a whole has a built-in LMS with existing content and a new sales training program. The Sales Manager has no current way to ensure the development of existing reps while also promoting the development of the 15 new reps.

The data sets contain not only average revenue, but also achieved revenue for a 60 person sales team each with a $2M quota. It’s common for most sales organizations to perform with averages representing the 20/60/20 rule. What this means is that the top 20% will be the top performers that often meet or exceed quota, the middle average represents the 60% percent that is often on or usually just short of meeting quota, and the bottom 20% are typically far below quota.

Let’s say Company A and B each had goals this quarter to contribute the most to revenue. The question most managers would ask is, “Where should I spend my time to make my job easier?

We can answer this by considering the above example. A performance improvement of 5% by the average-middle performers can be close to double that compared to the same increase for top performers. Equally important, even a 10 % increase in low performers productivity doesn’t even come close to the business impact of improving the middle performers’ productivity by 5%.

In other words, improving the middle contributes to 95.65% more revenue. This significance is compelling, even with ten sales reps, let alone 10,000 sales reps; managers should focus on delivering solutions to enhance the middle productivity. The deeper you dive into the data, the more you realize that improving the middle drives the most impact on productivity.

What’s the best way to do so? Looking at the two companies in more detail, it’s clear having the right knowledge is an important goal for both. Each month Company A spends a significant portion of a new reps time (5–7 weeks) on activities designed solely around knowledge delivery. Company B has the LMS and training tools ready for the 15 new sales to understand in terms of knowledge delivery. What this digestion typically looks like is a rep is coached on great storytelling, effectively handling questions, competitor information, and managing the sales process efficiently and consistently. The LMS houses all these resources and the hope is that the reps regularly use the system. What’s interesting to know is according to HR.com 70% of employee training is forgotten within five days. This means that teams must ensure that their sales reps can apply what they learn. It’s still necessary to coach at this knowledge introduction stage, but one key thing to keep in mind is that research has suggested that individuals learn 70% of their knowledge from on-the-job- experience, 20% from interacting with others, and 10% from studying and reading.

Company A and B have both invested heavily in sales enablement tools that hold knowledge. However, they will be better off if they can shift focus beyond learning delivery (Bootcamp experience/LMS knowledge) and instead improve how sales reps access the right pieces of knowledge to on the job quickly. The National Academies Press has shown that a key difference between an expert and and a novice is the experiences on which the expert has to draw on.

Senior sales reps win because they remember thousands of situations and plays more quickly and strategically because of their experience. New reps rely more on abstract rules— what to say to objections when the customer has a rebuttal, how to close the sale, etc. Both companies would benefit from finding a solution that reinforces moving the ‘abstract’ knowledge to strategic knowledge in a way that gathers knowledge without disrupting their workflow.

When your sales enablement strategy lacks the ability to maximize learning while on the job deals are lost. Sales teams should invest their time in solutions that promote this active learning process. How do your reps handle questions that they don’t know how to answer quickly? It shouldn’t involve shoulder tapping a peer. Having the resource or answer when you need it quickly is necessary for deals.

There’s good news and bad news. The bad news is that according to a study done by the CMO Council, sales reps waste over 40% of their time every day trying to find the resources and content needed to do their job. It’s also common sales knowledge that every 5% increase in selling time can amount to a 20% increase in revenue. Having a mechanism in place where your reps can proactively find the right content for each selling situation is important. When this mechanism works quickly, a rep is able to have answers to a question or find the right resource almost instantaneous they are more productive and learn on the floor. Now imagine if this process was automated within Slack, where the team lives daily, directly into reps workflows, so they don’t have to waste 40% of their time every day looking for the right resource. Sales Managers can expect to recognize their investment in new hires sooner, making it easier to focus efforts on coaching the middle performers.

Click here to learn how Obie helps you access the knowledge and assets you need to make faster decisions, without leaving Slack. So you can actually get things done.

Revenue is Optional: The Benefits of Making Your Middle Sales Reps More Productive was originally published in Obie.ai on Medium, where people are continuing the conversation by highlighting and responding to this story.