Gary Sieling

ZenDesk for web development projects: Project concept

Abstract

In the world of “web development”, many companies bundle offerings, in the hope of attracting small businesses that offer high-priced services. Bundled offerings typically including web development, SEO, social media marketing, search engine marketing, and whatever buzzword comes along next. These are pitched as lead generation. Examples of a client business are residentially-zoned lawyers, dentists, orthodontists, veterinarians, etc. A website is of high value, since a single customer nets a large return, but these businesses are typically unfamiliar with web design, SEO, online ads, and so on.

To exploit this market, many “SEO” or “marketing” or “web design” companies cold-call or cold-email small businesses to death. Regular people have trouble evaluating these companies, so they are likely to get burned by a shady vendor. Despite the natural lemon market, they are also often well-served by a hungry and well-run web development / marketing firms. The most successful of these seem to specialize in a specific industry (thus earning new business by referrals, rather than aiming a call center at a phone book). These clients typically lack an understanding of web development and must be guided carefully through a project. They are typically priced at a fixed monthly cost based on the value of new leads.

Because these companies aim to cultivate relationships with non-technical users, there is typically a lot of back and forth email threads for approvals to website changes, which is a nightmare for tracking. A better tool might keep the emails, but move the screenshots of website changes and tracking of approvals into a separate application. This allows the approver to feel like they are still having a conversation, but allows the vendor to treat the email threads like they are working in a ticketing system (this is essentially the ZenDesk model).

Opportunities / Challenges

This is the type of product that would naturally have referrals. If it is well-received, people would carry it with them as they switch jobs – it seems to be quite common for people who work for small consulting companies to go off on their own. It also is a natural fit for time tracking. For project management tasks, one could easily generate an audit history of all changes and how much time went into back and forth on revisions.

The downside of this type of product is that it must be easily comprehended by people who are non-technical. If you send people links to a page where they can approve a document, they will have difficulty remembering passwords, so one would be forced to make “secret” links. There is no guarantee that such a person will respond in a timely manner, which means the links can’t expire quickly.

If the application is built to approve changes based on screenshots, the end users must be able to identify that the screenshots aren’t actual, clickable screens. Since the purchaser of the product works as an intermediary, one would miss out on much valuable feedback.

A problem with any approval based system is knowing who made the approval (if it is forwarded or sent to a list), so this would need to be mitigated by tracking the IP of who accepted a change. Note that this could still mask people who are behind a firewall, but is useful in that you can tell how many people are actively looking at a document (the Atlassian product JIRA tells you who is currently viewing code reviews you’ve sent out for approval).

Software Design

A product of this nature would be most difficult if the number of classes of documents that could be approved was high. For instance, one might want to approve website changes with screenshots, or as text changes (more like Google Docs), or changes to video. This suggests that an inline commenting system is eventually desirable. It is also possible that situations that resemble proposal red-lining are too complex and should be discouraged for this type of application.

Exit mobile version