Smart Recommendations @ Werkspot

At Werkspot, we strive to become the easiest and most reliable way to arrange home services online! Our mission is simple:

  1. Delight consumers by connecting them with motivated & qualified service providers.
  2. Turbo-charge the ability of great service professionals to win jobs.

Every month, we have thousands’ of active service professionals interacting with the tens of thousands’ of service requests submitted by consumers. Connecting the right service request with the right service professional is non-trivial!

What tools do we use?

To tackle this challenge, we use state-of-the-art artificial intelligence algorithms.

In traditional software engineering, logic is encoded into a system using a series of hand-written rules (i.e. if-else statements). For example, one rule might be to only recommend service professionals that are within 50kms of the consumer. However, this list of rules could become incredibly long and still may not adequately capture the complexity of service professional preferences and the shifting dynamics in the home services market.

Artificial intelligence takes a different view. Instead, an algorithm (or model) looks at the data and tries to discover these rules for itself to optimise some objective (i.e. accuracy). Two familiar examples of artificial intelligence applications are Netflix movie suggestions and Amazon’s product recommendations.

How do we use these tools?

Our particular set of algorithms looks at the history of proposals on our platform and learn the preferences of service professionals for certain locations, job details, job sizes, seasons etc. For example, our recommendation system learns whether a service professional prefers indoor or outdoor painting in July, how many jobs in Amsterdam he is likely to propose for in the next month and whether he will travel 85km for a large kitchen renovation in Groningen.

We currently introduce these smart recommendations on the side of the consumer. When a consumer submits a service request, we recommend a list of service professionals that are highly likely to propose and win the job. The consumer can then view their profiles and send a direct request to these service professionals to contact them about their job.

Screen Shot 2018-12-21 at 13.33.33

In this way, Werkspot promotes transparency and consumer choice, while rewarding top service professionals with unprecedented access to highly-engaged consumers!

What’s next?

We are only just beginning on our journey to revolutionise the experience of our users with artificial intelligence. A logical next step is to provide smart recommendations to service professionals, whereby we alert them to service requests that are predicted to be highly attractive to them. We strongly feel that this will dramatically cut down the search costs that service professionals incur to find, propose and win jobs!

The new data analytics pipeline at Werkspot

Werkspot is the easiest and most reliable way to arrange home services. With the objective of beating “word of mouth” and becoming the primary channel for hiring service professionals, we at Werkspot have worked towards building a scalable platform to provide a user-friendly experience to the customers and service professionals.

In order to achieve the objective, our business strategies play a key role along with software development to bring value to customers and service professionals that want to engage with each other. To help our management team and product owners to devise the best strategies, data plays a significant role. Data provides the feedback loop that allows managers to not only verify the success and failure of the business strategies but also helps them polish their future goals, set expectations and improve strategies for better results. To be able to reinvent their plans, it is important not only to present the data in a very consistent manner but also be able to present relevant facts to end business users without them having to dig through the entire dataset.

Currently, we use Looker as the BI tool to visualize the insights from different sources of data. Important information related to Service Requests and Service Pros, Advertising costs and their associated ROI, sales team activities and financial data are made reachable to the end business users through the use of Looker views. The Data Engineering team is responsible for using the data from relevant sources and building reports in Looker to cater to the needs of our business users.

One of the advantages that Looker provides is the ability for the data engineering team to build analytics in looker without having to worry about setting up an underlying architecture to support the analytics computation. Looker is also a development driven environment with version control integrations. So data engineers can collaborate on projects for developing the required analytics in a distributed manner through their own branch on Looker, that is a working copy of the production. However, there are always two sides to a coin. With all the analytics in the Looker, it demands heavy computation. Looker explorers are a collection of various facts about a similar object. They are created by joining various relevant tables to a base table on a join parameter. These joins are expensive and therefore use up a lot of database capacity. This also shows an architectural dependency in Looker, where business related facts can only be presented by following their modeling guidelines. This results in higher query times for the relevant information to be shown to the end business user. This also makes difficult for new changes to be applied to the analytic model. The needs of the business users are expected to change over time as they focus on different KPIs to improve their business process.

To remove this overload and achieve a higher database efficiency, we are moving the analytics modeling in Looker to a different layer. Fig. 1 shows the new data analytics pipeline that we at Werkspot are moving towards.

Blank Diagram (1)

Fig 1 – New data analytics pipeline

The first layer in the pipeline is the EL layer (Extraction and Loading). Raw data from various sources are extracted and stored in our data warehouse using Stitch, ready to be ingested by the Analytics layer. Stitch is an enterprise tool that allows users to extract data from relevant sources and load it directly to their data warehouse without having to build the pipelines themselves. This layer doesn’t allow any queries to be run from the end business users’ side. High priority is given towards automating the entire process and achieving robustness with fewer developer hours. For the analytics layer, an open source tool called DBT (data build tool) shall be used to transform the raw data into relevant facts sought out by business users. Finally, the transformed data or facts will be presented to our end users through Looker. With this new analytics model, we are essentially moving to an ELT based approach, where the data from various sources is first loaded into a data warehouse and transformations are made on the data warehouse directly. There are various advantages to the above model:-

  1. The entire analytics from Looker has been moved to an underlying layer, which will result in higher Looker efficiency.
  2. One advantage of working with DBT is an enhancement in the quality of data. DBT will allow us to write both SQL and business-related tests to validate the data we are providing to our end users.
  3. Fewer scripts to maintain and higher maintainability due to shift from ETL to ELT.
  4. With analytics in an independent layer and therefore no architectural impediments, Dimensional modelling will be used to achieve higher predictability, maintainability and scalability of our Analytics layer.

Data warehouse modelling in Werkspot started with the objective of building a dimensional model. However, due to the fact that the entire analytics was built into Looker and the fact that Looker has its own architectural dependency, the current analytics is a complex version of both Entity-relationship and dimensional modelling. With the above undergoing project, we aim to bring back the model to a pure dimensional form. Ralph Kimball was the developer of this modelling concept and it basically involves segregating your data warehouse into dimensions and facts. Facts would mean the end KPIs that are of interest to the business. For our platform, one example could be the number of proposals made by service professionals on a particular day. Dimensions are the contexts that are used to build the facts. Carrying on with the above example, dimensions associated with the fact could be:-

  • Service requests associated with the proposals
  • Service professionals making the proposals
  • Time of proposal etc.

Facts and dimensions in dimensional modelling are represented through a star schema where fact is the primary table containing the foreign keys to the dimensional tables. Ralph Kimball and Margy Ross provide a nice visualization for the star schema using the example of Retail Sales in Fig 2.


Fig 2 –Dimensional Model Visualization for a Retail Sales

There are various advantages of using dimensional modelling for our data warehouse. They bring in extra simplicity and understanding of the data for the business users. In dimension modelling, if two facts are called by the same name, they have to mean the same thing. Therefore they bring in more coherence to our data warehouse and a better understanding of KPIs among all our end business users. Our present analytics in looker can be rebuilt with fewer joins and therefore, it will decrease the computation load and enhance our data warehouse performance to a great extent. Also in terms of scalability, it is more convenient to scale up the data warehouse during business expansion. In dimensional modelling, there is a granularity in which dimensions and facts are defined. Ideally, the granularity should be atomic, meaning you cannot trickle down to something more granular. In that case, if scaling up requires new dimensions and facts in our data warehouse, it would be very easy to initiate change without impacting the whole data warehouse. Also with dimensions and measures separated out, reusability of data increases to a great extent. Currently, with our legacy analytics model in looker, a lot of views use dimensions and measures that are dependent on other views. Therefore an explorer uses up way more SQL joins than it requires.

Though the advantages stated above are in theory, they are significant enough to make the change. However, a detailed analysis needs to be carried out when this transition is completely over. We are hopeful that the new analytics model will be beneficial to the entire company in terms of data delivery and computational efficiency.

Hoping for the best with fingers crossed!

Bridging the Gap — produce and communicate design decisions that are essential to code

How can we improve our UX/UI practice by borrowing some of the development’s points of view? How can we create useful design deliverables? How might we improve communication with developers to solve design problems in more creative ways? And ultimately how might we make devs ❤️ love working with us?…

On June ’18 Ladies That UX Amsterdam had the pleasure of having Rayana Verissimo give a workshop about Bridging the Gap between design and development. These are my takeaways from the workshop:

How we work and why we struggle

As the years pass, what we UX-ers do for a living gets more complex and new tools are created. We have to choose and master the right tool for the right kind of project.

From crafting your deliverables the right way to a specific audience, to learning how you can better work with people in different roles, from users to developers, all this is the foundation for your craft.

“There’s a lot more to design than just ‘design’ ”.

The journey from an idea to a great product requires clear communication and close collaboration between design and development teams. We need to be equipped with all possible knowledge to make that a reality. Even with the shared understanding, there’s still a visible gap between those two roles that are so important for creating products.

We have the chance to get closer, especially now that we live in a world full of design systems, style guides, and guidelines — us designers aim for reusability, consistency and clarity.

The ‘unfortunate workflow’ from designer to developer

The design process has several stages. It begins with understanding our users, what they want, the current problem and what’s wrong with the existing solution. After understanding, we jump to sketching and generating a bunch of ideas before narrowing them down into the design stage.

The ideas that survive will be designed and mocked down from low to high fidelity before prototyping. The more fidelity we add to the prototypes, the more time is spent refining them to look like the final application.

Sketching and prototyping are essential for what we do. A chart by the Nielsen Norman group shows that almost 90% of designers produce static wireframes as deliverables.

This chart ranks the deliverables by the percentage of UX professionals who reported producing them either “often” or “sometimes”. Wireframes and prototypes were most commonly produced, followed by flowcharts, sitemaps, and usability/analytics reports.

When it comes to communicating ideas to developers, interactive prototypes were chosen as being the most effective. Style Guides are also becoming increasingly popular as a design/dev deliverable because it’s focused strongly on structural details and interaction specifics that are critical for implementation purposes.

This chart shows the percentage of survey respondents that reported each type of deliverable as being effective for communicating with developers and engineers.

In most processes, when the prototype is what we want our design to look like, then we are ready to move forward to the development stage. This is when we meet developers with our mockups, explaining why they were designed the way they were.

There might be a chance developers start to criticise the ideas, asking questions, suggesting new ideas and saying that something will take ‘AGES’ to implement.

As a result, we need to re-iterate our designs, include ideas and limitations that we heard from engineers and spend more time working on the mockups…

You wasted your time working on a solution that is not ideal and your developers are sad. Everybody is sad. I’m sad to tell that story…

The problem with this approach …

Is that developers are usually not included in ‘OUR process’ from the beginning, understanding the why behind the design decisions. Wireframes and prototypes are very expensive assets.

“At this phase in particular where the final artefact — your product — doesn’t exist yet, provides a bunch of opportunities for collaboration.”


  • Include developers in early stages of discovery
  • Don’t wait too long to share your prototypes
  • Prototypes are expensive — know when to spend time on them
  • Designers have a shared language. Developers can be very technical. Build bridges, not walls 🙂


Design with the developer in mind

In order to make our lives easier, we have to design for development. This means finding the solution that produces the best user experience with the least amount of effort.

A design that looks great on Sketch but takes too much effort to be implemented or breaks the codebase every time a developer needs to implement a change does not deliver great design.

That’s why design systems are so successful —  they allow us to design in a systematic, modular way, and this is extremely valuable for how a product is coded. Designing with development in mind is about working as a team, not merely completing a step in a process.

Just like you need to empathise with your users, you should apply the same mindset towards your development team.

Designing together helps everyone to be more informed, invested and empathetic with users from the start.

Remember that developers are just designers of code and ultimately everyone is working towards the same goal — whether it seems like it or not.

We cannot bridge the gap if we’re not open to let other people influence our jobs.

It’s not to say our processes should be led by development. It’s a two-way street. In more mature teams, developers think with the designer in mind. We have frameworks to help achieve that, such as the Atomic Design by Brad Frost.


But it doesn’t hurt to say: Fight for great UX 💪

Always keep in mind that when a design decision has a clear benefit to the user, it should be developed (or at least considered). Don’t let a developer talk you out of it if it’s absolutely a better user experience.

Use whatever facts and sources you can to explain your position, but most importantly:

  • Ask your developers how you can help get things done before flipping out or giving up on your design.
  • Investigate whether there’s a way to create a similar effect with less development effort. There’s always a workaround. You can work with the bare-minimum and plan improvements for future iterations of a feature.
  • When an argument can be made either way about whether an item, design element, or feature benefits the user, choose the path that makes the code more reusable, consistent, or clean. Again, design systems are accelerators to our craft.
  • Invite them to usability testing, show the real value for a real user.


Things you should be asking your developer


#1 — Are there any limitations for the product? ✋

Why: User interface design as discussion about feasibility, progressive enhancement, and responsive layouts.

The first step we have to take is to predict UI and UX limitations that may (and probably will) arise during development.

  • Present sketches on early stages to understand content hierarchy and layouts, or how can things progressively improve in different devices
  • Know what kind of information you have to work with, the data, API
  • Keep in mind / ask about limitations of HTML 5, CSS3, or whatever language is being used


#2 — What browsers do we need to support? ☝️

Why: Browsers read web pages differently. We can influence, but we cannot control the user experience.

Knowing which browsers you support can help you understand some default behavior of the interface, if animations are supported, and also dig into the amount of customizability that will be needed in the code to apply our design changes.

  • Predict how elements will look without the added effects in legacy browsers and provide solutions (progressive enhancement)
  • Certain component’s controls cannot be customized with CSS
  • Understand that typography and colors render differently in different browsers
  • Reference:


#3 — Will the product be built using a front-end framework? 🛠️

Why: Knowing the framework will help us make safer decisions and set-up our deliverables the right way.

There are many popular frameworks available that take a lot of the tedious work out of the design and development process. You don’t need to figure out things by yourself.

  • Set baseline for grid and breakpoints
  • Many frameworks come with built-in design elements like buttons, forms, tooltips, etc
  • Defined global values: padding, column width, gutter width…
  • Official documentation will help find out if a component has dependencies


#4 — How are properties being reused in the CSS? 🤹‍

Why: visual properties are always shared through the CSS, knowing where helps you keep a consistent UI

  • Modern CSS preprocessors allow reuse of properties for color, pixels, borders, etc.
  • Important to keep consistency across components.
  • It allows easy customization of an app’s UI (think white-label products).
  • Learn more: creativebloq


#5 — How should assets be prepared? 🎁

Why: Devs have preferences too.

  • Do they prefer you slice, prepare and save all assets into an organized folder?
  • A layered source file that they extract the images from themselves?
  • PSD? Sketch? Invision? Zeplin?
  • Do they have the same version of the software/access?
  • How can you group and name the layers to help them find and isolate the assets they need?


#6 — Should the assets be accompanied by a handoff document? 📖

Why: You might need to provide extra details.

  • Handoff documents should be simple and easy to read.
  • Talk about the granularity of details necessary for development.
  • Sometimes tools that provide annotation and code inspect are not the best choice.
  • You can choose to deliver a visual style guide.


Things UX can do (to bridge the gap)


#1 Learn the medium we’re designing for

  • When designing a mockup you should be able to see how it can be built from a developer’s perspective.
  • For example, an input field is created using an HTML tag and styled with CSS.
  • You don’t need to know how to write this code but you should know the basics of how form inputs are generated.
Example form element:

#2 Consider studying a few of these topics

  • Learn how HTML tags are nested and rendered in the browser
  • The basics of CSS and how it differs from HTML
  • How CSS properties are used to create effects like box shadows
  • Which elements can be created using pure CSS vs. which elements require images
  • How breakpoints work in responsive website layouts
How the web works:

#3 Keep accessibility in mind from the start

  • Some visual decisions we make hurt overall web accessibility requirements.
  • Research what can be customized in the UI before deviating from its original shape.
  • Something changed in the code because of a design decision can hurt your users.

Some visual decisions that we make hurt overall web accessibility requirements. Always make sure you are covering basic accessibility guidelines in your prototypes.

For example, placeholders in form fields are harmful to accessibility.

Placeholder text within a form field makes it difficult for people to remember what information belongs in a field, and to check for and fix errors. It also poses additional burdens for users with visual and cognitive impairments.

Also, not all browsers allow placeholder text to be styled using CSS, this is a difficult issue to mitigate.

According to NN/g, the best approach for it would be placing the label and hint outside the form field so they are always visible to the user.

#4 Be consistent

  • Align everything nicely along the grid, or introduce any other kind of visual order.
  • Use a consistent color scheme throughout the app.
  • Keep the navigation consistent across all screens.
  • Re-use the same elements for different situations. For example, design a sample notification and color-code it for different situations.

Inconsistent design generates inconsistent code. Code and design define performance. Also, we know the value of consistent design. Consistency makes users feel comfortable, saves time and money, and let us focus on innovating in other solutions. 🏆

#5 Break your design down into pieces

  • You can break large designs into small, cycle-sized pieces that focus on UI Components and incrementally add elements to the overall design.
  • Remove the components from the app context.
  • Define acceptance criteria for each component.
  • Document non-functional requirements.

We tend to deliver our final designs as a stack of slides. Maybe you deliver them on Invision, Zeplin, whatever tool… Maybe it’s something the developer can click through and those links will kind of reflect the user journey for that feature.

It’s quite fine but not excellent because our prototypes are normally built in a very complex way.

Looking at how agile teams work, we can break large designs into small, cycle-sized pieces that focus on UI Components and incrementally add elements to the overall design.

When you show the component in context over and over again it kind of loses the context of all its details, so focus instead on interaction states. You want the developers to be able to focus on this single problem instead of overwhelming them with the whole interface.

Everything is covered and it works pretty well for everyone.

By breaking designs apart, we have the opportunity to investigate, prototype, and usability test design chunks, carrying the progressively built design forward until it is complete and reviewed with the developers. Then, we pass the finished design to the developers for implementation.

“This example shows an interaction of a dropdown component that allows selection of multiple items. The UI shows all the states, default, hover, disabled. One thing you might notice it’s missing here is all the context of the app around it.”

Summary 💪

WOW! There’s so much we have to know to be kick-ass designers!

  • Find the balance between how you deliver assets to devs.
  • The web is complex, but learning the foundations of web design can only help us, HTML/CSS are essential.
  • Focus on solid learning — tools get deprecated.
  • Use a modular/component-based approach to design.

About the Author

Like this post? Stay up to date with me on MediumTwitter and LinkedIn.

Deployments with containers

This post is part of The Containerization Chronicles, a series of posts about Containerization. In them, I write about my experiments and what I’ve learned on Containerization of applications. The contents of this post might make more sense if you read the previous posts in this series.

Now that we have the project integrated with a Continuous Integration server, where we run the tests and report back to GitHub pull requests with the results of the test run and the coverage, we can deploy our project and make it available on the Internet.

We will do so with Heroku. I have chosen Heroku because it allows me to perform these experiments for free.

If you want to jump into the code, this is the tag for this post.

Continue reading …

Continuous Integration with containers

This post is part of The Containerization Chronicles, a series of posts about Containerization. In them, I write about my experiments and what I’ve learned on Containerization of applications. The contents of this post might make more sense if you read the previous posts in this series.

Now that we have some containers in place for development, we can integrate with a CI server. I chose Scrutinizer CI because of the code analysis it makes, the fact that it is also a CI server it’s a plus. However, as a CI, it has some limitations, which I will talk about later on when integrating with Heroku, so we will most likely move to another CI engine later in the future while keeping Scrutinizer only for the code analysis but, for now, this is all we need.

To set up the CI, we will:

  1. Containerize an environment to run the tests in the CI
  2. Configure Scrutinizer
  3. Add the scrutinizer badges to the
  4. Integrate Scrutinizer with GitHub

If you want to jump right into the code, this is the tag on GitHub.

Continue reading here

The week of security at Werkspot / Instapro

Last week we organized the week of Security. A week dedicated to increasing the security awareness of our employees. When it comes down to security you might think our developers and product owners are pretty aware of the risks, but the interest and results show different. This post is about some activities we organized and what we learned in order to improve the security awareness within Werkspot/Instapro.


To get started we thought about a way to get everyone motivated. A great way to have everyone involved was adding a competition component. Everyone could earn “Security coins” for each challenge. The one with the most coins at the end of the week could win one of the amazing security prizes. The winner would receive the Security Gnome!

Dedicated Slack Security Channel

At Werkspot/Instrapro we are big fans of Slack. To get started we asked everyone to join our security channel. This way we can communicate certain security risks and no matter whether someone is working from home, at the office, or be commuting, all of us are pretty quickly up to date.

Surprisingly this resulted not only in people joining the channel, but started to share security issues and helping each other out. Pictures of unlocked machines, keys at desks and paper at printers that were left behind were mentioned in this channel.

Daily security tips & posters

To keep everyone engaged in this week of security, we put up some simple posters about the do’s and don’ts on security. Related to this we send daily tips on how to handle phishing emails, multi-factor authentication (MFA) and awareness of your social activities in relation to security.

Phishing emails and follow upphishing.png

By (Own work) [CC BY-SA 4.0 (, via Wikimedia Commons

Receiving spam is something we all receive in our inboxes on a daily basis. To train our employees we use Phishme to send Phishing emails and support the ones that do click on the link by providing training.
Phishme is providing plenty of scenario’s and templates for catching a recipient on matters of urgency, emotions or even “great deals”. We decided to send emails about losing your last year’s vacation days as well as tax-related messages. In multiple languages, we provided training material so people were still able to read what they could improve. Within a couple of months, we will do the same exercise and see if we improved the awareness.

Show how to crack passwords

It’s great to inform people about the risks and warn them about the way they choose passwords or don’t make use of MFA, however, showing how hackers actually could resolve your password is making the risk more real.
We invited the whole company to join a session where we showed the different ways of brute force login on a website, social engineering for retrieving the password and a live demo of using the tool Hashcat to decrypt passwords.

With a database of 20k encrypted passwords within minutes, we decrypted a couple hundred. Most of the people were amazed by seeing a plain text password coming out of a hash that actually worked to log in to a real website.

Final words

The week of security is, with a small amount of effort, a great way to improve security awareness in any organization. Even as a tech company there is enough to learn and enough material available to increase this awareness. My main takeaway is, provide enough information, make it rewarding to join and show some real-life examples of how certain security issues happen.

And the winner is…

Here at Werkspot, we like to work together with educational partners. As part of our innovation network, Strategic Product Design (Master) students of Delft University of Technology worked on design cases. The projects of these students were a little different than usual. Students are used to working in the waterfall approach. The cases here at Werkspot were coached differently: They did three sprints according to the agile methodology and Scrum framework. Within those sprints they adhered to the lean approach. Multiple experiments were conducted, ranging from interviews, paper prototyping and smokescreens via email campaigns. One can discuss what makes an MVP an MVP; what is sure is real end-users generated insights to form the concepts and strategies on.

Two hours before the pitching starts the students start to shuffle in. A mixture of excitement and nerves can be seen on each of their faces. Each of the groups prepared a 5-minute pitch on the concept they worked on for 10 weeks. After a short energizer which filled the meeting room with loud youthful noises we went through all slide decks. Everyone was well prepared and ready as a duck. One student asked: “How many people can we expect?”. When I estimated fifty, her eyes opened wide with delight and anxiety: “Wow, that’s more than I expected”. When the students arrived upstairs, one could easily spot who was going to present of each group: wiggling on their feet and drinking a lot of water. The bar was opened and Werkspotters started to gather around. Time for the first pitch.

Pitch 1: Offerty streamlines communication

The first pitch was done by 3xA Design (each grouped named themselves). They envisioned that Werkspot should help in facilitating easy and open communication between the service professional and the consumer. Their concept was Offerty, an app that gives an easy to use overview of the jobs they are working on. Consumers can receive updates about their job as the SP works on the job.

Screen Shot 2018-02-05 at 16.39.38.png
Offerty allows for easy communication between the service professional and the consumer. Click the image for a demo.

Pitch 2: First aid for theft

The second pitch found an interesting insight during their research: Service professionals are all afraid their equipment gets stolen. The app EHBD (‘Eerste hulp bij diefstal’, Dutch for first aid for theft) aims to get rid of the hassle after a theft. Easy communication with their insurance, a digital overview of their tools and an overview of what info you need to supply to the police. Click here to see a demo.

Screen Shot 2018-02-05 at 16.44.22.png
Theft is a very prevalent topic under service professionals


Pitch 3: Chatpro engages in conversation

One of the cases focused on creating a more delightful experience for consumers. Describing their job can be hard. Customers feel misunderstood about the job that they want to get done. Chatpro’s team proposed a strategy of layering on various interaction methods, ranging from an improved form, a Werkspot Expert and AI supported chatbots to enable a conversational UI.


Pitch 4: Werk+ enables a community

Werk+ was the fourth pitched concept. They found that trust and quality are hugely important for consumers to use our platform. Their proposed vision was to enhance the feeling of community to enable this trust. An interactive map with social media integrations would enhance the feeling of community.

Screen Shot 2018-02-05 at 16.52.23.png

Pitch 5: Werkplan visualizes the job

The last pitch was done by Bananabrand. Their research showed that service professionals like to feel appreciated. A consumer-first oriented app allows the consumer to ask for advice on more specific details in the entire job. This is a standalone app, yet allows for a direct job posted on Werkspot. This way the consumer is better informed and the service pro can offer advice where needed.

Screen Shot 2018-02-05 at 16.55.50.png

Werkplan wins the audience award

50 minutes down the road and the first award ceremony was about to take place. The audience gets to vote on their favourite concept. Voters take out their smartphone and rethink which concept should win. As the votes started to pour in it soon became clear that Werkplan won the audience award by a landslide. A warm applause and cheering sounded from the audience and the team moved forward to collect their award (an engraved hammer).

Team BananaBrand claims their audience award!

And the jury award goes to…

The jury, consisting of Ronald (CEO), Kris (CSO) and Jaap (CTO), retreats to a meeting room. While the door shuts slowly, the sound from the audience gets softer and becomes inaudible. The jury expressed their appreciation of the proper presentation skills but comes down to business right away. Two concepts were closely tied to their potential and the link with Werkspot stood out.

Ronald (CEO) discusses the pros and cons of each concept before announcing the winner..

The jury walks out of the meeting room. For one last time that afternoon I passed the microphone to Ronald. The audience went silent and all the eyes were aimed at Ronald. He goes over each of the pitches. As he announced the runner-up, the winning team looks excited and confused. Later one of the members will explain: “I was not sure whether we won or not.” When Ronald said the words “Which makes us come to the winner, Chatpro”, cheering followed. Based on their strong integration plan and direct integration potential, Chatpro snatches the jury award from their competition. They have shown that they understand the problems a consumer faces and offer a technically feasible solution. Well done!

The Chatpro team happily claims there award

After one and a half hour, the formal part is over. Teams are happy the semester has been put to an end. They happily grab some drinks from the bar and discuss their concepts with the Werkspotters even further. Some of the students went on to discover the nightlife of Amsterdam. All I can say is that as an innovation manager and as a teacher I can recommend this kind of collab to anyone.

Written by Jeroen Coelen. I’m an innovation manager at Werkspot and a part-time teacher at TU Delft, focusing on design strategy and entrepreneurship.