Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Understand and plan around PO based large requesters #48

Open
markwhiting opened this issue Jan 7, 2018 · 2 comments
Open

Understand and plan around PO based large requesters #48

markwhiting opened this issue Jan 7, 2018 · 2 comments
Assignees

Comments

@markwhiting
Copy link
Member

The problem

A large company contacted us regarding becoming a requester as an enterprise. This requires us supporting a new way of taking payment which is generally called a purchase order (PO). POs are formal agreements for one company to spend money in a certain way through another company, and as a consequence they often involve:

  1. contractual agreements or invoices
  2. bank transfers using a special protocol

The problem here is that we have not done this before and we don't fully understand the implications of doing it, or even have in place the mechanisms to try. So, we need to find out more, and decide if we want to pursue this kind of option for this large requester and other potential large requesters.

For context, requesters of this type generally have the PO style agreements with other players in the crowdsourcing market, and generally have internal rules baring them from doing this kind of business (buying human activity of some kind) without POs.

For further context this proposal is the first step toward the strategic milestone #33 and less specifically, #36.

My proposal

There are a few phases as I understand it:

  1. Understanding what we are able to do with our current setup. i.e. our relationship to Stanford and our payment partner Stripe.
  2. If any changes are required, understand their implications on a short and long term, before taking any actions.
  3. Deciding which actions we should like to take to pursue large requesters.

What's involved?

This would basically involve chatting with a range of people at Stanford, Stripe and the large requester, to find out what our options are and what their implications might be. After establishing that we would formulate a plan which could then become a separate proposal if needed.

Implications

In the short term, getting more requesters #36 and, in particular getting big requesters #33 are important steps for us to grow and continue improving. Trying to understand and plan around this is valuable, and should not pose any harm.

In the longer term, understanding these kinds of things better will help us know how to position Daemo for different sized organizations, and may help us think about aspects that could be important to our eventual legal entity status.


Use comments to share your response or use emoji 👍 to show your support. To officially join in, add yourself as an assignee to the proposal. To break consensus, comment using this template. To find out more about this process, read the how-to.

@markwhiting markwhiting self-assigned this Jan 7, 2018
@qwertyone
Copy link
Contributor

Expect delays between the smaller and larger requesters. Unlike the former payment system I was familiar, the purchase order system will require a review from within the corporation to get funding. I would anticipate that there would be a group of people who need to sign off on it to become a legal contract. It would be helpful to locate a purchasing specialist nearby to ask how things might work by understanding generic organizational goals along the way.

@markwhiting
Copy link
Member Author

Thanks and agreed regarding the potential delays. Some of the potential contacts at Stanford and Stripe are specialists in these domains so hopefully they should be able to provide enough insight. Of course, if more details are needed, we can pursue other alternatives.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants